February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1236) Theme Maple contains image that removes dashboard navigation links

by Anders Andersen (JIRA)

Theme Maple contains image that removes dashboard navigation links ------------------------------------------------------------------ Key: JBPORTAL-1236 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1236 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Theme Affects Versions: 2.6.Alpha2, 2.6.Alpha1 Environment: mac osx 10.4.8, Firefox 1.5.0.9 + Safari + Mozilla Reporter: Anders Andersen Assigned To: Julien Viet Priority: Minor When I select the maple theme I become unable to navigate to link "Edit Content" and unable to see my name. This seems to be because an image is floating on top of the links. If a user is so unlucky to add maple to all pages he/she is unable ever to get back to the edit-conent. I did that ofcause :-) I then later tried to remove the user (by admin), but when I recreated the user the dashboard settings was the same (maple). I think this is a bug as well. I will report this seperately -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1214) Use the same URL key for the map of web app to deployed portlet applications

by Julien Viet (JIRA)

Use the same URL key for the map of web app to deployed portlet applications ---------------------------------------------------------------------------- Key: JBPORTAL-1214 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1214 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.Alpha1, 2.4.1 SP1, 2.2 Branch Reporter: Julien Viet Assigned To: Julien Viet Fix For: 2.2.2 Final, 2.6.Beta1, 2.4.2 Final -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-3675) Add LockOwnerName to ThreadDump output from ServerInfo

by Darran Lofthouse (JIRA)

Add LockOwnerName to ThreadDump output from ServerInfo ------------------------------------------------------ Key: JBAS-3675 URL: http://jira.jboss.com/jira/browse/JBAS-3675 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-4.0.4.GA Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: JBossAS-4.0.6.CR1 The current thread dump shows what object a thread is waiting on but it does not show which thread currently owns the lock. Add getLockOwnerName for each thread output. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4091) Transaction issue with separate JBoss jars

by Don Seiler (JIRA)

Transaction issue with separate JBoss jars ------------------------------------------ Key: JBAS-4091 URL: http://jira.jboss.com/jira/browse/JBAS-4091 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager Affects Versions: JBossAS-4.0.5.GA Environment: RHEL 3, Sun JDK 5 (1.5.0_07) Reporter: Don Seiler Assigned To: Adrian Brock Recently we have tried to separate our EJB Project out into two parts. One project to handle all of our persistence and another to handle all of our service's. The persistence project was set up to serve out entity objects back through a DAO service. This way our Service project can just call into our DAO services and retrieve the information that they would need and allowing for a nice split between two different types of projects. However, in the process of separating these projects out we hit some issues with the transaction manager not flushing upon the call of the flush command. The flush command is something we greatly rely on as a means to make sure our data is persisted underneath the proper user in the database through contexts. It is also the means in which we can allow support of oracle proxy connections. We achieved this by having a PrepareDatabaseConnection AOP method; which is executed before and after a method is called. Allowing for us to set the database context after the transaction is started and to close the database context before the transaction ends. Ideally we would have liked to hook it directly onto the begging and end of the transaction but we couldn't find a great way to do so. So instead on every one of our services and DAO work we added the PrepareDatabaseConnection interceptor to properly set our database context or to configure the connection as a proxy connection. In a single jar this functionality works great. However, in separate jars we start to see issues with the database context not being properly set, which leads to issues with auditing what users changed the data in the database. In a single jar the contents flush upon my call to the entity manager to commit / update the information. However, when these are separate jars the flush doesn't occur until the transaction manager tells it to flush and close the transaction. At which point in time the database context has already been unset leaving no record of which user was actually using that connection from the connection pool. Why is it when we move the database code out to a separate jar the entity managers flush doesn't actually flush the information when it was requested to? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

2
3
0 / 0

[JBoss JIRA] Reopened: (JBAS-1489) MessageListener does not invoke ExceptionListener on error

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1489?page=all ] Adrian Brock reopened JBAS-1489: -------------------------------- > MessageListener does not invoke ExceptionListener on error > ---------------------------------------------------------- > > Key: JBAS-1489 > URL: http://jira.jboss.com/jira/browse/JBAS-1489 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1 > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossAS-4.0.2RC1, JBossAS-3.2.8 Final > > > If SpyMessageConsumer detects an error on the MessageListener thread > it should invoke the ExceptionListener. > Also, to avoid potential deadlocks with exceptions detected on the MessageListener > thread, a new thread should be started to invoke the ExceptionListener. > Otherwise the ExceptionListener will not be able to close the consumer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1489) MessageListener does not invoke ExceptionListener on error

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1489?page=all ] Adrian Brock closed JBAS-1489. ------------------------------ Resolution: Done > MessageListener does not invoke ExceptionListener on error > ---------------------------------------------------------- > > Key: JBAS-1489 > URL: http://jira.jboss.com/jira/browse/JBAS-1489 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1 > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossAS-3.2.8 Final, JBossAS-4.0.2RC1 > > > If SpyMessageConsumer detects an error on the MessageListener thread > it should invoke the ExceptionListener. > Also, to avoid potential deadlocks with exceptions detected on the MessageListener > thread, a new thread should be started to invoke the ExceptionListener. > Otherwise the ExceptionListener will not be able to close the consumer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1489) MessageListener does not invoke ExceptionListener on error

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1489?page=all ] Adrian Brock updated JBAS-1489: ------------------------------- Fix Version/s: JBossAS-3.2.8 Final > MessageListener does not invoke ExceptionListener on error > ---------------------------------------------------------- > > Key: JBAS-1489 > URL: http://jira.jboss.com/jira/browse/JBAS-1489 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS service > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1 > Reporter: Adrian Brock > Assigned To: Adrian Brock > Fix For: JBossAS-4.0.2RC1, JBossAS-3.2.8 Final > > > If SpyMessageConsumer detects an error on the MessageListener thread > it should invoke the ExceptionListener. > Also, to avoid potential deadlocks with exceptions detected on the MessageListener > thread, a new thread should be started to invoke the ExceptionListener. > Otherwise the ExceptionListener will not be able to close the consumer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1217) User registration, usability issue

by Thomas Heute (JIRA)

User registration, usability issue ---------------------------------- Key: JBPORTAL-1217 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1217 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.Alpha1 Reporter: Thomas Heute Assigned To: Roy Russo Fix For: 2.6.Beta1 There is a usability problem with user registration: - Click on "You can create an account" - Fill the form - Submit - it leads to a maximized user portlet with a unique link: "Standard login" - Click on the unique link - It brings you to a page saying "You are currently not logged in" Confusing :) I guess that after submission it should show the "You are currently not logged in" in a minimized window, where there is a "Login" link on the theme. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

3
3
0 / 0

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

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2854?page=all ] Adrian Brock updated JBAS-2854: ------------------------------- Component/s: JCA service (was: JMS service) Assignee: Weston Price (was: Adrian Brock) > 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: JCA service > Affects Versions: JBossAS-4.0.4RC1 > Reporter: Adrian Brock > Assigned To: Weston Price > 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, 2 months

1
0
0 / 0

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

by Adrian Brock (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2854?page=comments#action_12353080 ] Adrian Brock commented on JBAS-2854: ------------------------------------ Re-assigned to Weston since this is in the JCA JMS outbound adapter. > 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: JCA service > Affects Versions: JBossAS-4.0.4RC1 > Reporter: Adrian Brock > Assigned To: Weston Price > 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, 2 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 February 2007