October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBAS-2100) AOP integration in JBoss5

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2100?page=comments#action_12345360 ] Kabir Khan commented on JBAS-2100: ---------------------------------- It will depend on AOP 2.0. alpha 2 http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&pid=1005... > AOP integration in JBoss5 > ------------------------- > > Key: JBAS-2100 > URL: http://jira.jboss.com/jira/browse/JBAS-2100 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: MicroContainer bus > Reporter: Adrian Brock > Assigned To: Kabir Khan > Priority: Blocker > Fix For: JBossAS-5.0.0.Beta > > > TODO: Bill > 1) Describe target AOP version and link the release task to this JBossAS integration task. > 2) Add extra integrations tasks/tests to this task. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAOP-91) Annotation interoperability

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-91?page=all ] Kabir Khan closed JBAOP-91. --------------------------- Resolution: Done > Annotation interoperability > --------------------------- > > Key: JBAOP-91 > URL: http://jira.jboss.com/jira/browse/JBAOP-91 > Project: JBoss AOP > Issue Type: Task > Reporter: Adrian Brock > Assigned To: Kabir Khan > Fix For: 2.0.0.alpha2 > > > Need to test annotation interoperability between different jvm versions. > 1) Serialization of annotations from/to java5 <-> pre java5 (annotationc) > 2) annotationc generationed annotations should work with java5 > 3) investigate something like retroweaver modifications so developers can work with one > codebase rather than having mulitple source trees for the different techniques/versions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAOP-296) Get aop build and tests working w/ Jboss retro

by Kabir Khan (JIRA)

Get aop build and tests working w/ Jboss retro ---------------------------------------------- Key: JBAOP-296 URL: http://jira.jboss.com/jira/browse/JBAOP-296 Project: JBoss AOP Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.alpha2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
3
0 / 0

[JBoss JIRA] Updated: (JBAOP-91) Annotation interoperability

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-91?page=all ] Kabir Khan updated JBAOP-91: ---------------------------- Fix Version/s: 2.0.0.alpha2 Assignee: Kabir Khan (was: Bill Burke) JBoss AOP now has a JDK 5 codebase and uses with jboss retro for compatibility with JDK 1.4. > Annotation interoperability > --------------------------- > > Key: JBAOP-91 > URL: http://jira.jboss.com/jira/browse/JBAOP-91 > Project: JBoss AOP > Issue Type: Task > Reporter: Adrian Brock > Assigned To: Kabir Khan > Fix For: 2.0.0.alpha2 > > > Need to test annotation interoperability between different jvm versions. > 1) Serialization of annotations from/to java5 <-> pre java5 (annotationc) > 2) annotationc generationed annotations should work with java5 > 3) investigate something like retroweaver modifications so developers can work with one > codebase rather than having mulitple source trees for the different techniques/versions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-614) Remove shutdown logger

by Tim Fox (JIRA)

Remove shutdown logger ---------------------- Key: JBMESSAGING-614 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-614 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Alpha1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Alpha2 It is not needed any more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-146) XAError during commit is reported as retriable by the participant when it should be a heuristic

by Mark Little (JIRA)

XAError during commit is reported as retriable by the participant when it should be a heuristic ----------------------------------------------------------------------------------------------- Key: JBTM-146 URL: http://jira.jboss.com/jira/browse/JBTM-146 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation, JTS Implementation Affects Versions: 4.2 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.2.1 An XAException with errorcode -7 is RMFAIL, which means that the transaction coordinator does not know what state the resource manager is in. It may have committed or it may have rolled back (it could have done this autonomously). This may be a permanent failure of the resource manager or it may only be transient; the transaction manager has no way of knowing. At this point the transaction outcome is potentially non-atomic (an heuristic outcome) and outside the scope of the TM to try to resolve automatically. In ATS 4.0.2, the failure during commit was masked and commit would return committed. What happened was that the failed resource was retained in the transaction log and recovery would try to complete the transaction later. This silent behaviour was wrong (a bug): the application needs to know that a potential heuristic outcome has occurred. Therefore, in ATS 4.0.3 the error is handled differently (correctly): the transaction will throw a heuristic exception and, as before, retain the reference to the XAResource in the hopes that the log can be used to resolve the potential heuristic. The failure recovery subsystem retry mechanism has not changed. However, because the failure reported from the XAResource has changed, this impacts what failure recovery will do. In 4.0.2, the error (wrongly) was reported as being something that failure recovery could automatically try to deal with. Hence, when the recovery manager ran and found the log entry that referenced your XAResource, it would try to complete the transaction. In 4.0.3, the error is a heuristic, which cannot be managed automatically: that is the whole point of a heuristic error. It needs manual intervention. In this case, the recovery manager will ignore the log entry and do nothing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3771) Simple redeploy causes leak

by B D (JIRA)

Simple redeploy causes leak --------------------------- Key: JBAS-3771 URL: http://jira.jboss.com/jira/browse/JBAS-3771 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-4.0.4.GA Environment: windows xpsp2 clean jboss install default configuration Reporter: B D Assigned To: Dimitris Andreadis I am using the simple ear file found at http://www.roseindia.net/jboss/anttutorialcode.zip and constantly reploding it with something like this @ECHO OFF cls SET COUNT=0 SET PATH=E:\tools\apache-ant-1.6.5\bin;%PATH% set SERVLET_LIB_JAR=E:\tools\Maven\repository\servletapi\jars\servletapi-2.3.jar :Loop call touch E:\dev\anttutorialcode\anttest\example2\src\HelloWorld.java call ant rem xcopy /f /y example2.ear E:\server\jboss-4.0.2\server\default\deploy >nul: xcopy /f /y example2.ear E:\server\jboss-4.0.4.GA\server\default\deploy >nul: SET /A COUNT=COUNT+1 echo Deployed EAR file count is %COUNT%, sleeping 30 secs... sleep 30 goto Loop There is a leak of 1mb every few minutes! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAOP-295) Update tutorial examples to use jdk 5 (and jboss retro for jdk 1.4)

by Kabir Khan (JIRA)

Update tutorial examples to use jdk 5 (and jboss retro for jdk 1.4) ------------------------------------------------------------------- Key: JBAOP-295 URL: http://jira.jboss.com/jira/browse/JBAOP-295 Project: JBoss AOP Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.alpha2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBSEAM-426) Stateful bean destruction wants extended EM to join a transaction and fails

by Christian Bauer (JIRA)

Stateful bean destruction wants extended EM to join a transaction and fails --------------------------------------------------------------------------- Key: JBSEAM-426 URL: http://jira.jboss.com/jira/browse/JBSEAM-426 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.1 Reporter: Christian Bauer @Name("register") @Scope(ScopeType.CONVERSATION) @Stateful public class RegisterBean implements Register { @In private User currentUser; @In(create = true) private EntityManager caveatEmptorEM; @In(create=true) private transient FacesMessages facesMessages; private String verifyPassword; public String getVerifyPassword() { return verifyPassword; } public void setVerifyPassword(String verifyPassword) { this.verifyPassword = verifyPassword; } @Begin(join = true, flushMode = FlushModeType.MANUAL) public String enterAccount() { System.out.println("################### FLUSHMODE" + ((HibernateEntityManager)caveatEmptorEM).getSession().getFlushMode()); if ( verifyPasswordMismatch(currentUser.getPassword()) || usernameExists(currentUser.getUsername()) ) { return null; // Redisplay page } else { return "profile"; } } @IfInvalid(outcome = Outcome.REDISPLAY) public String enterProfile() { return "confirm"; } @End public String doRegister() { System.out.println("################### FLUSHMODE" + ((HibernateEntityManager)caveatEmptorEM).getSession().getFlushMode()); // This is also wrong, different issue if ( usernameExists(currentUser.getUsername()) ) return "register"; caveatEmptorEM.persist(currentUser); caveatEmptorEM.flush(); // Remove the "currentUser" from the session context. This is a detached object // after this method returns. We don't want it to leak into the next conversation! Contexts.getSessionContext().remove("currentUser"); facesMessages .addFromResourceBundle("SuccessfulRegistration"); return "login"; } @Remove @Destroy public void destroy() {} ... } Exception during @Destroy: 00:03:34,505 DEBUG [org.jboss.seam.contexts.Contexts] destroying: conversation 00:03:34,505 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.preDestroy.conversation 00:03:34,505 DEBUG [org.jboss.seam.contexts.Contexts] destroying: register 00:03:34,505 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.preDestroy.register 00:03:34,506 DEBUG [org.jboss.seam.Component] trying to inject with hierarchical context search: caveatEmptorEM 00:03:34,506 DEBUG [org.jboss.seam.contexts.Contexts] found in conversation context: caveatEmptorEM 00:03:34,507 DEBUG [org.jboss.seam.util.Naming] JNDI InitialContext properties:{java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces} 00:03:34,507 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.preRemoveVariable.register 00:03:34,507 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.postRemoveVariable.register 00:03:34,507 DEBUG [org.jboss.seam.interceptors.RemoveInterceptor] Stateful component was removed: register 00:03:34,508 WARN [org.jboss.seam.contexts.Contexts] Could not destroy component: register javax.ejb.EJBException: java.lang.IllegalStateException: EntityManager is closed at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:69) ... Caused by: java.lang.IllegalStateException: EntityManager is closed at org.hibernate.ejb.EntityManagerImpl.getSession(EntityManagerImpl.java:42) at org.hibernate.ejb.AbstractEntityManagerImpl.joinTransaction(AbstractEntityManagerImpl.java:447) at org.hibernate.ejb.AbstractEntityManagerImpl.joinTransaction(AbstractEntityManagerImpl.java:442) at org.jboss.seam.core.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:91) at sun.reflect.GeneratedMethodAccessor328.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.seam.util.Reflections.invoke(Reflections.java:17) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:101) at org.jboss.seam.Component.callComponentMethod(Component.java:1642) at org.jboss.seam.Component.unwrap(Component.java:1663) at org.jboss.seam.Component.getInstance(Component.java:1501) at org.jboss.seam.Component.getInstance(Component.java:1461) at org.jboss.seam.Component.getInstanceToInject(Component.java:1688) at org.jboss.seam.Component.injectFields(Component.java:1218) at org.jboss.seam.Component.inject(Component.java:988) at org.jboss.seam.interceptors.BijectionInterceptor.bijectTargetComponent(BijectionInterceptor.java:48) I can't make the doRegister() method @End @Remove @Destroy, it throws exceptions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-747) bad documentation

by Jon Stevens (JIRA)

bad documentation ----------------- Key: EJBTHREE-747 URL: http://jira.jboss.com/jira/browse/EJBTHREE-747 Project: EJB 3.0 Issue Type: Bug Components: Documentation Reporter: Jon Stevens http://docs.jboss.org/ejb3/app-server/tutorial/relationships/relationship... @JoinTable(table = @Table(name = "flight_customer_table"), joinColumns = {@JoinColumn(name = "FLIGHT_ID")}, inverseJoinColumns = {@JoinColumn(name = "CUSTOMER_ID")}) the "table =" is wrong. This url...has it correct... http://docs.jboss.org/ejb3/app-server/tutorial/relationships/src/org/jbos... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2006