January 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-3221) Need to rewrite JBossMQ tests to be more robust

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3221?page=all ] Dimitris Andreadis updated JBAS-3221: ------------------------------------- Issue Type: Task (was: Bug) Change the issue from bug to task. > Need to rewrite JBossMQ tests to be more robust > ----------------------------------------------- > > Key: JBAS-3221 > URL: http://jira.jboss.com/jira/browse/JBAS-3221 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JMS service, Test Suite > Affects Versions: JBossAS-4.0.4.GA > Reporter: Scott M Stark > Fix For: JBossAS-4.2.0.CR1 > > > Repeated runs of the JMSContainerInvokerQueueMessageDrivenUnitTestCase on my laptop (1.6GHz Pentium M) will result in the following failure: > <testcase classname="org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase" name="testRestartJMS" time="30.891"> > <error message="Wrong number of messages, expected=2 > got=1" type="java.lang.Exception">java.lang.Exception: Wrong > number of messages, expected=2 got=1 > at org.jboss.test.messagedriven.support.CheckMessageSizeOperation.run(CheckMessageSizeOperation.java:46) > at org.jboss.test.messagedriven.support.BasicMessageDrivenUnitTest.runTest(BasicMessageDrivenUnitTest.java:112) > at org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase.testRestartJMS(JMSContainerInvokerQueueMessageDrivenUnitTestCase.java:67) > From Adrian: > The fundamental problem is waiting on a timeout for asynchronous work which will be subject to all sorts of random failures if for example you run it on your laptop while you are doing compiles or downloading e-mail. > The thread doing the wait (or the server thread doing the work) simply doesn't get scheduled in time because the cpu is busy. > The hard part is when you do a wait and you expect nothing to happen in that wait time. You don't want to slow down the testsuite doing long waits. > In general, these tests can be written better, but doing so also means testing things beyond the spec like looking at service instrumentation to check there is no outstanding work to performed before asserting state. > e.g. The jms queue is empty or a thread pool has no scheduled work, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-2854) Fire local transaction events from the jms resource adapter

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2854?page=all ] Dimitris Andreadis reassigned JBAS-2854: ---------------------------------------- Assignee: Adrian Brock Assigned to Adrian if he has the time to implement this for the current release. > Fire local transaction events from the jms resource adapter > ----------------------------------------------------------- > > Key: JBAS-2854 > URL: http://jira.jboss.com/jira/browse/JBAS-2854 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.4RC1 > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossAS-4.2.0.CR1 > > > We need to fire local transaction events from the jms resource adapter. > This is not a trivial change since there is currently no easy way for the JmsSession class > to work out when the transaction started and whether it is a local transaction. > There is no explicit start of transaction in JMS. > It probably needs a modfication to getSession() as this is the most obvious point > where work is first done in a new transaction after the commit/rollback on the session. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-2842) Add support for stopping ILs triggering the ExceptionListener

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2842?page=all ] Dimitris Andreadis reassigned JBAS-2842: ---------------------------------------- Assignee: Adrian Brock Assigned to Adrian if he has the time to implement this for the current release. > Add support for stopping ILs triggering the ExceptionListener > ------------------------------------------------------------- > > Key: JBAS-2842 > URL: http://jira.jboss.com/jira/browse/JBAS-2842 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.4RC1 > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossAS-4.2.0.CR1 > > > As per the super task which is a fix to make sure client exception listeners > get triggered if somebody stops the server, this same behaviour should > occur if somebody just stops the IL. > This involves making each IL keep track of their respective connections. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2342) Remoting integration issues

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2342?page=all ] Dimitris Andreadis closed JBAS-2342. ------------------------------------ Fix Version/s: (was: JBossAS-4.2.0.CR1) Resolution: Out of Date This is tracked here: JBAS-3272 > Remoting integration issues > --------------------------- > > Key: JBAS-2342 > URL: http://jira.jboss.com/jira/browse/JBAS-2342 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Remoting > Reporter: Scott M Stark > > A container task for remoting integration issues for the jboss-4.0.4 release -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2360) Application deployed as an ear fails, but succeeds when deployed exploded.

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2360?page=all ] Dimitris Andreadis closed JBAS-2360. ------------------------------------ Fix Version/s: (was: JBossAS-4.2.0.CR1) Resolution: Out of Date > Application deployed as an ear fails, but succeeds when deployed exploded. > -------------------------------------------------------------------------- > > Key: JBAS-2360 > URL: http://jira.jboss.com/jira/browse/JBAS-2360 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3 Final, JBossAS-4.0.3RC2 > Environment: GNU/Linux (Fedora Core 4); kernel 2.6.13-1.1526_FC4, i386. > Reporter: Stephen Saucier > > When application is deployed in a directory with a suffix of .ear, it deploys fine. > When application is deployed as a jar file with a suffix of .ear, it complains that my ejb-jars are invalid, with an error message ending " is not an EJB .jar file!" > My ejb-jar files contain only the EJB bean implementation class files (and deployment descriptors), the interfaces and other supporting classes are packaged in a ejb client jar, and are referenced by the ejb-jar using a Class-Path entry in the Manifest. This should be a valid mechanism for deployment, according to the ejb 2.1 spec. > I'm pretty confident that the standard deployment descriptors are without problem since this application was previously running on a different application server, but it is possible the problem is coming from one of my jboss deployment descriptors (but I doubt it). Additionally, since the application deploys fine when not deployed in a jar file but in a directory, I don't think the problem is coming from my application. > I followed the directions on the wiki to restore J2EE compliant classloader behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-2038) Need to externalize the JBossEntityResolver configuration and support namespace to schema resolution

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2038?page=all ] Dimitris Andreadis reassigned JBAS-2038: ---------------------------------------- Assignee: Alexey Loubyansky Assigning to Alex, together with the enclosing issue. > Need to externalize the JBossEntityResolver configuration and support namespace to schema resolution > ---------------------------------------------------------------------------------------------------- > > Key: JBAS-2038 > URL: http://jira.jboss.com/jira/browse/JBAS-2038 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: XML services > Reporter: Scott M Stark > Assigned To: Alexey Loubyansky > Fix For: JBossAS-4.2.0.CR1 > > Attachments: catalog.xsd > > > With the increased use of JBossXB and its leveraging of the JBossEntityResolver as a means for locating element schemas, we need support for externalizing the configuration of the JBossEntityResolver. We also need to have the notion of resolving a namespace to a schema URI since in general there is no publicID for an element, and a generally unsable systemID since it can be a function of the deployment and server run dir. > Implementing the javax.xml.transform.URIResolver resolve method: > public javax.xml.transform.Source resolve(String href, String base) > throws javax.xml.transform.TransformerException > might be a better api for resolving namespaces. > I have tried integrating the apache commons xml catalog resolver but have not been happy with its semantics and configuration support as yet. We certainly could at least use the catalog.xml schema for representing the externalized mappings. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2923) Making JCA security more pluggable

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2923?page=all ] Dimitris Andreadis updated JBAS-2923: ------------------------------------- Assignee: Weston Price Weston, assigning to you if you have time to take this up now, or defer for a next release. > Making JCA security more pluggable > ---------------------------------- > > Key: JBAS-2923 > URL: http://jira.jboss.com/jira/browse/JBAS-2923 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JCA service > Reporter: Adrian Brock > Assigned To: Weston Price > Fix For: JBossAS-4.2.0.CR1 > > > We need a mechanism to make JCA security more pluggable. > This is to cater for use cases where some extra context needs to be used. > The connection manager only understands a subject. > The connection factory (e.g. DataSource) only understands the CRI (method parameters). > The pooling uses both without needing to understand what they are in detail. > This change would provide a "wrapper" connection manager that can do things > more associated to context, e.g. it could be connection factory specific, > i.e. it understands the CRI and can do things that the connection factory doesn't do > or it can do things based on information. > An example of other information would allowing a per deployment > security domain such that you have different pre-configured user/password per ejb. > With something like the following in META-INF/jboss-[web].xml > <jboss> > <enterprise-beans> > <session> > <ejb-name>Whatever</ejb-name> > ... > <resource-ref> > <res-ref-name>jdbc/DataSource</res-ref-name> > <jndi-name>java:/MySQLDS</jndi-name> > <security-domain>FooBar</security-domain> > </resource-ref> > </session> > </enterprise-beans> > </jboss> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2077) Add retry to CachedContext

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2077?page=all ] Dimitris Andreadis updated JBAS-2077: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 (was: JBossAS-4.2.0.CR1) > Add retry to CachedContext > -------------------------- > > Key: JBAS-2077 > URL: http://jira.jboss.com/jira/browse/JBAS-2077 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: JBossAS-4.0.3RC1 > Reporter: Adrian Brock > Fix For: JBossAS-4.2.1.CR1 > > > If the ExternalContext's cachedContext receives a javax.naming.CommunicationException, it should attempt > to retry (configurable) the request after recreating the context/connection. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

Que tienen en común?

by FonoIP

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-826) Incorrect action exception handling

by Pedro Silva (JIRA)

Incorrect action exception handling ----------------------------------- Key: JBPM-826 URL: http://jira.jboss.com/jira/browse/JBPM-826 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.3 Environment: Eclipse + Tomcat + JDK 6.0 Reporter: Pedro Silva Assigned To: Tom Baeyens Priority: Critical If an action in a process definition throws an exception it doesn't correctly reach the client class, e.g. the class doing the signalling. Imagine that you have a process definition that in one of the task as an action that opens a file for reading. If the file cannot be found there will be an exception. Te exception is thrown and when it reaches the class, where the code for signalling is, you can't see the exception message. If you try to do, in the catch block, System.err.println(e.getMessage()) the result is null! However if you print System.err.println(e.getCause().getMessage()) the result is the file not found exception. This is worst in the case when you caught the exception in the action delegated class and you throw your own exception by explicitly doing: throw new MyException("Some error"); and the message still is null. In the case where the exception occurs in another class than the one of the action (if the execute code of the action invokes another class), even the code System.err.println(e.getCause().getMessage()) outputs null. The documentattion clearly states in 9.7 Exception Handling: "...Uncaught exceptions are thrown to the client (e.g. the client that called the token.signal()) or the exception is caught by a jBPM exception-handler. ..." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2007