February 2010 - jboss-dev-forums - Jboss List Archives

[JBoss Transactions Development] New message: "Re: @TransactionTimeout(...) doesn't have effect with com.arjuna.ats.jbossatx.jta.TransactionManagerService"

by Petteri Hietavirta

JBoss development, A new message was posted in the thread "@TransactionTimeout(...) doesn't have effect with com.arjuna.ats.jbossatx.jta.TransactionManagerService": http://community.jboss.org/message/523710#523710 Author : Petteri Hietavirta Profile : http://community.jboss.org/people/pepez Message: -------------------------------------------------------------- We are having the same problem with @TransactionTimeout annotation on JBoss 5.1.0.GA. I've posted a question to StackOverflow as well but no solution yet: http://stackoverflow.com/questions/2184844/jboss-transaction-timeout-setting -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523710#523710

14 years, 11 months

1
0
0 / 0

[JCA Development] New message: "Re: JBJCA-201 - New validation rules"

by Vicky Kak

JBoss development, A new message was posted in the thread "JBJCA-201 - New validation rules": http://community.jboss.org/message/523684#523684 Author : Vicky Kak Profile : http://community.jboss.org/people/vickyk Message: -------------------------------------------------------------- Jeff, what is the status of this task? I am planning to work on this task, please confirm if you have not already started with it yet. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523684#523684

14 years, 11 months

1
0
0 / 0

[JBoss Web Development] New message: "Re: Strange behaviour of org.xml.sax.EntityResolver.resolveEntity method on JBOSS"

by Shivey Upadhyay

JBoss development, A new message was posted in the thread "Strange behaviour of org.xml.sax.EntityResolver.resolveEntity method on JBOSS": http://community.jboss.org/message/523664#523664 Author : Shivey Upadhyay Profile : http://community.jboss.org/people/Shivey Message: -------------------------------------------------------------- Another Observation: The above code is using weblogic.xml.jaxp.RegistrySAXParserFactory in weblogic and org.apache.xerces.jaxp.SAXParserFactoryImpl in JBoss, is there any equivalent http://java.sun.com/javase/6/docs/api/javax/xml/parsers/SAXParserFactory.... supported by JBoss, that provides what is specified as SYSTEM in DOCTYPE declaration as is (i.e., without applying prefix)? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523664#523664

14 years, 11 months

1
0
0 / 0

[jBPM Development] New message: "Re: Disabling Hibernate logs"

by Sakthivelmurugan K G

JBoss development, A new message was posted in the thread "Disabling Hibernate logs": http://community.jboss.org/message/523660#523660 Author : Sakthivelmurugan K G Profile : http://community.jboss.org/people/kgsakthivel Message: -------------------------------------------------------------- hi, Thanks for your reply. Do you mean to say the log4j.properties file? I don't have it in my application. But then how is it logging? Regards, Sakthi -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523660#523660

14 years, 11 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: Possible bug introduced in AbstractController?"

by Ales Justin

JBoss development, A new message was posted in the thread "Possible bug introduced in AbstractController?": http://community.jboss.org/message/523658#523658 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > However, I am unsure how to test this. What about if you override the Logger instance in Controller for this test? The field is private, but reflection is your friend. :-) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523658#523658

14 years, 11 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: Possible bug introduced in AbstractController?"

by Kabir Khan

JBoss development, A new message was posted in the thread "Possible bug introduced in AbstractController?": http://community.jboss.org/message/523656#523656 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- Following server startup I have tried modifying both deployers/jboss-logging.deployer/META-INF/logmanager-jboss-beans.xml and deploy/jboss-logging.xml and no longer see the error with my local kernel snapshot. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523656#523656

14 years, 11 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] New message: "Re: Possible bug introduced in AbstractController?"

by Kabir Khan

JBoss development, A new message was posted in the thread "Possible bug introduced in AbstractController?": http://community.jboss.org/message/523646#523646 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I have fixed this https://jira.jboss.org/jira/browse/JBKERNEL-87 However, I am unsure how to test this. I added this to OnDemandDependencyTestCase public void testNoUglyError() throws Throwable { //FIXME This simply runs what used to cause the ugly error mentioned in JBKERNEL-87. //I am not sure how to actually test that this does not happen since errors on uninstall //are not reported back to the user. TestDelegate delegate1 = getDelegate1(); ControllerContext context1 = assertInstall(delegate1, ControllerState.DESCRIBED); TestDelegate delegate2 = getDelegate2(); ControllerContext context2 = assertInstall(delegate2); assertContext(context1); assertUninstall(context1); //What triggered the error assertContext(context2, ControllerState.CONFIGURED); assertNull(context2.getError()); assertNull(context1.getError()); } -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523646#523646

14 years, 11 months

1
0
0 / 0

[EJB 3.0 Development] New message: "Re: Externalizing Scope: Resolving EJB References and Endpoints"

by Carlo de Wolf

JBoss development, A new message was posted in the thread "Externalizing Scope: Resolving EJB References and Endpoints": http://community.jboss.org/message/523643#523643 Author : Carlo de Wolf Profile : http://community.jboss.org/people/wolfc Message: -------------------------------------------------------------- Again, this problem was already resolved a long time ago. It's called home interfaces. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523643#523643

14 years, 11 months

1
0
0 / 0

[JBoss AOP Development] New message: "Re: ClassPool Refactoring"

by Flavia Rainone

JBoss development, A new message was posted in the thread "ClassPool Refactoring": http://community.jboss.org/message/523640#523640 Author : Flavia Rainone Profile : http://community.jboss.org/people/flavia.rainone@jboss.com Message: -------------------------------------------------------------- After porting JBAOP-765, JBAOP-768 and JBAOP-763 to JBoss AOP branch 742, I still see a couple of failures, both related to subclassing tests. It took me a while, but I finally discovered what is causing those failures. The problem is in the classpool structure. By some unexpected reason, the parent class pool of ExtClassLoader is a classpool representing a class loader that belongs to default domain. Since ExtClassLoader is parent of the parent of the default domain, that classpool is in the delegation chain of itself. It also belongs to the delegation chain of other classpools, which is clearly a bug. This bug manifests itself only on corner cases, and it can be seen only by debugging Javassist. That's why it was so hard to find out. For example, one of the failures I was seeing, in AOPUnitTestCase, was happening because the access to POJO.protectedField below was not woven. public class POJOChild extends POJO { ... public void accessProtectedField() { protectedField += 1; System.out.println("protectedField = " + protectedField); } } JBoss AOP Transformer was doing everything correctly, but the javassist CodeConverter was failing to replace the accesses to protectedField above by calls to the wrapper methods of such joinpoints. I discovered that, once the CodeConverter found those accesses, it matched the name of the field correctly, but it failed to match the class that declares the protectedField, because it obtained a CtClass instance representing POJO that was not the same instance contained in the CodeConverter, even though both instances represented the same classes (one of the instances was retrieved from the correct class loader, the other one was not). Now, I'll investigate to see why the classpool hierarchy is wrong, so I can find out how to fix it. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523640#523640

14 years, 11 months

1
0
0 / 0

[JBoss Portal Development] New message: "Re: [portlet container] actionURL generated too long because of large render parameter?"

by Chen Wang

JBoss development, A new message was posted in the thread "[portlet container] actionURL generated too long because of large render parameter?": http://community.jboss.org/message/523639#523639 Author : Chen Wang Profile : http://community.jboss.org/people/chenwang Message: -------------------------------------------------------------- Thanks Thomas. Yes I was looking at those 2 classes and didn't feel right about them. Is it possibly to have a more robust implementation of the url renderer added to the controller module of portlet container project? I would have thought that only the module assemblying simple-portal war was for demo purpose so not quite production ready but other modules should be good? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523639#523639

14 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2010