February 2010 - jboss-user - Jboss List Archives

[JBoss Tools] New message: "Re: Adding JBoss AS source to a project"

by henk de boer

User development, A new message was posted in the thread "Adding JBoss AS source to a project": http://community.jboss.org/message/523662#523662 Author : henk de boer Profile : http://community.jboss.org/people/henk53 Message: -------------------------------------------------------------- > mailto:max.andersen@jboss.com wrote: > > If your project is setup to locate sources correctly then any debug launches that refer to that project should also work - if not then please report a bug. Forgive my ignorance, but how do I exactly setup my project to locate sources correctly? Maybe strongly related, but by default the debugger also can't find the sources in my project itself. I'm really not doing anything special. Just a new download of Eclipse 3.5.1 Java EE edition. Installed nothing else but Jboss AS tools for that Eclipse version. Used clean new workspace. Then I created a new EAR project, added a JSF page with a backing bean. On the JSF page is basically only a h:outputText with EL referring to the bean. I put a break point in the bean and startup Jboss 5.1 via the Servers view. Load the page in my browser, the break-point hits and Eclipse/WTP/Jboss AS tools says it can't find the source of my bean. Using the debug view I then add both the EJB and web projects to the source lookup and then it can find the source of the .java file that is directly in the project. Is there anything I need to do in advance somewhere? It really strikes me as odd that ctrl-click just works when I create the bean, but then the debugger can't find the source after the break point hits. I tried on both my Mac at home and Ubuntu at work. A friend of my who also uses Jboss AS tools reported the same problem and also never found a solution. Am I missing something or is this a bug? I haven't yet tried with the default generic Jboss 5.0 runtime that is bundled with WTP though, so I'll try that too to see if it differs (although I really don't like the bundled Jboss runtime, since it's only capable of doing packaged deployments). -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523662#523662

16 years, 2 months

1
0
0 / 0

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

by Sakthivelmurugan K G

User 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

16 years, 2 months

1
0
0 / 0

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

by Ales Justin

User 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

16 years, 2 months

1
0
0 / 0

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

by Kabir Khan

User 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

16 years, 2 months

1
0
0 / 0

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

by Kabir Khan

User 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

16 years, 2 months

1
0
0 / 0

[jBPM] New message: "Description tag not parsed for activities?"

by Sofie Ravyts

User development, A new message was posted in the thread "Description tag not parsed for activities?": http://community.jboss.org/message/523645#523645 Author : Sofie Ravyts Profile : http://community.jboss.org/people/sravyts Message: -------------------------------------------------------------- As a workaround to http://community.jboss.org/message/518323#518323 we are using the description tag to store the name of an activity for use in the UI. For tasks this works very well. The task "description" property is read from the jpdl when parsing the task definitions. But for our custom activities, there doesn't seem to be a description after parsing. When I looked at the code (JpdlParser.java line 308), Element descriptionElement = XmlUtil.element(documentElement, "description"); if (descriptionElement!=null) { String description = XmlUtil.getContentText(descriptionElement); activity.setDescription(description); } I noticed the documentElement description tag is parsed instead of the nestedElement description tag. Could it be that documentElement needs to be replaced with nestedElement in this part of code or am I seeing it completely wrong? Wkr, Sofie -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523645#523645

16 years, 2 months

1
0
0 / 0

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

by Carlo de Wolf

User 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

16 years, 2 months

1
0
0 / 0

[JBoss Web Services] New message: "namespace are not referenceable from schema document"

by sasanka samal

User development, A new message was posted in the thread "namespace are not referenceable from schema document": http://community.jboss.org/message/523641#523641 Author : sasanka samal Profile : http://community.jboss.org/people/sekhar_25 Message: -------------------------------------------------------------- Hi , I have genarated java files from WSDL file which has multiple schema imports just like this< wsdl:import namespace=+"http://www.tmforum.org/mtop/mri/wsdl/rir/v1-0"+ location=+"ResourceInventoryRetrievalMessages.wsdl"+/> and I have implemented endpoint interface in other java file using webservice annotation and deployed into JBOSS 4.2.3 I am getting the below error . pls find below @ WebService(name = "ResourceInventoryRetrieval_RPC", targetNamespace = "http://www.tmforum.org/mtop/mri/wsdl/rir/v1-0") **public ** * *class* ResourceInventoryRetrievalRPCImpl *implements* ResourceInventoryRetrievalRPC{} * *ERROR:-* 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:activityName' to a(n) 'element declaration' component. 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:msgName' to a(n) 'element declaration' component. 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:msgType' to a(n) 'element declaration' component. 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:senderURI' to a(n) 'element declaration' component. 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:destinationURI' to a(n) 'element declaration' component. 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:replyToURI' to a(n) 'element declaration' component. 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:originatorURI' to a(n) 'element declaration' component. 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:failureReplytoURI' to a(n) 'element declaration' component. 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:activityStatus' to a(n) 'element declaration' component. 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:correlationId' to a(n) 'element declaration' component. 17:02:37,720 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:security' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:securityType' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:priority' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:msgSpecificProperties' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:communicationPattern' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:communicationStyle' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:requestedBatchSize' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:batchSequenceNumber' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:batchSequenceEndOfReply' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:iteratorReferenceURI' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:fileLocationURI' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:compressionType' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:packingType' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:timestamp' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns1:vendorExtensions' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns2:topic' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] JBossWS_v1_0.notc.wsdl.fmw.mtop.tmforum.org_5965124913372431712.xsd[domai...: Cannot resolve the name 'ns2:message' to a(n) 'element declaration' component. 17:02:37,736 ERROR [JBossXSErrorHandler] [domain:http://www.w3.org/TR/xml-schema-1]::[key=src-resolve.4.2]::Message...: Error resolving component 'ns1:commonEventInformation'. It was detected that 'ns1:commonEventInformation' is in namespace 'http://www.tmforum.org/mtop/fmw/xsd/cei/v1', but components from this namespace are not referenceable from schema document 'null'. If this is the incorrect namespace, perhaps the prefix of 'ns1:commonEventInformation' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'null'. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/523641#523641

16 years, 2 months

1
0
0 / 0

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

by Flavia Rainone

User 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

16 years, 2 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

User 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

16 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-user February 2010