January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4580) "INFO [STDOUT] fromPath: <fieldname>" is logged during startup

by Wolf-Dieter Fink (JIRA)

"INFO [STDOUT] fromPath: <fieldname>" is logged during startup -------------------------------------------------------------- Key: JBAS-4580 URL: http://jira.jboss.com/jira/browse/JBAS-4580 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: CMP service Affects Versions: JBossAS-4.0.5.GA Environment: JBoss_4_0_5_GA_CP04 date=200705011622 Reporter: Wolf-Dieter Fink Assigned To: Alexey Loubyansky Priority: Trivial After the migration from 4.0.4=>4.0.5_GA_CP04 the following is logged: INFO [STDOUT] fromPath: o.validFrom INFO [STDOUT] fromPath: o.validTo TRACE [org.jboss.ejb.plugins.cmp.jdbc.EJBQLToSQL92Compiler] ejbql: SELECT OBJECT(o) FROM SoldComponentAssoc o, SoldComponent sc, SoldProduct sp WHERE o.sold Component.soldComponentId = sc.soldComponentId AND o.soldProduct.soldProductId = sp.soldProductId AND sp.isDead = false AND sc.account.accountId = ?1 AND o.validFrom <= ?2 AND o.validTo > ?2 AND o.soldComponentName LIKE ?3 all fields that are displayed are special classes which are mapped with JDBCParameterSetter, JDBCResultSetReader, Mapper Classes. looks like a forgotten System.out.println() -- 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

17 years, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3914) Thread dumps from ServerInfo MBean do not contain line breaks.

by Darran Lofthouse (JIRA)

Thread dumps from ServerInfo MBean do not contain line breaks. -------------------------------------------------------------- Key: JBAS-3914 URL: http://jira.jboss.com/jira/browse/JBAS-3914 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JMX Affects Versions: JBossAS-4.0.5.GA Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: JBossAS-4.2.0.CR1 Thread dumps from ServerInfo MBean do not contain line breaks, as the output HTML and displayed in a browser this is generally not a problem as the browser formats the output using the HTML tags not based on the presence of line breaks. If users copy the data from the web browser to a text editor as there are no line breaks in the original output the data is pasted to the text editor without breaks which causes everything to be on one line. The ouput thread dumps should have line breaks added to get round this. -- 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

17 years, 11 months

5
7
0 / 0

[JBoss JIRA] Created: (JBAS-4852) EJB3 web service endpoints ignore metadata in jboss.xml

by Thomas Diesler (JIRA)

EJB3 web service endpoints ignore metadata in jboss.xml ------------------------------------------------------- Key: JBAS-4852 URL: http://jira.jboss.com/jira/browse/JBAS-4852 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler Assigned To: Carlo de Wolf Fix For: JBossAS-4.2.2.GA This is related to JBWS-1813 It needs to be decided whether jboss-4.2.2 can go out despite this issue. Currently, users are forced to use annotations on the bean. -- 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

17 years, 11 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-4636) Fix org.jboss.test.deployers.* failures

by Dimitris Andreadis (JIRA)

Fix org.jboss.test.deployers.* failures --------------------------------------- Key: JBAS-4636 URL: http://jira.jboss.com/jira/browse/JBAS-4636 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta3 Looking at the testsuite runs: http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/... There is a whole group of deployer tests that need to be further qualified/fixed, with linked issues created org.jboss.test.deployers.client.test 4 4 0 6.208 org.jboss.test.deployers.ear.test 5 5 0 10.343 org.jboss.test.deployers.ejb.test 4 4 0 9.456 org.jboss.test.deployers.jbas2904.test 1 1 0 1.659 org.jboss.test.deployers.rar.test 4 4 0 6.285 org.jboss.test.deployers.sar.test 4 4 0 16.937 org.jboss.test.deployers.web.test 4 4 0 30.319 -- 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

17 years, 11 months

4
12
0 / 0

[JBoss JIRA] Created: (JBXB-116) When unmarshalling a repeating element which is a subclass of the declared type, in some cases only the last elmeent is stored in java object

by Karen Lease (JIRA)

When unmarshalling a repeating element which is a subclass of the declared type, in some cases only the last elmeent is stored in java object --------------------------------------------------------------------------------------------------------------------------------------------- Key: JBXB-116 URL: http://jira.jboss.com/jira/browse/JBXB-116 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-1.0.0.CR11 Environment: Windows XP, Java 5, jboss 4.2.1.GA with jbossws-2.0.x.GA (jboss-xml-binding 1.0.0CR11) Reporter: Karen Lease I have a bug unmarshalling an array of objects in a jaxrpc webservice. The method is declared as purchase(String, Product[]). If I call the method with an array of ProductA (which is a subclass of Product), then the deserialized Product array only contains 1 element which is always the last one in the array which is being sent. For example, if the incoming SOAP message is: <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'> <env:Header/> <env:Body> <ns1:purchase xmlns:ns1='http://org.jboss.ws/samples/docstyle/wrapped/types' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'> <String_1>Karen</String_1> <arrayOfProduct_2 xsi:type='ns1:ProductA'> <name>cyfac</name> <price>3000</price> </arrayOfProduct_2> <arrayOfProduct_2 xsi:type='ns1:ProductA'> <name>look</name> <price>5000</price> </arrayOfProduct_2> <arrayOfProduct_2 xsi:type='ns1:ProductA'> <name>GOSPORT</name> <price>1000</price> </arrayOfProduct_2> </ns1:purchase> </env:Body> </env:Envelope> the array in the purchase method is passed only the ProductA('GOSPORT',1000). Using the method purchaseA(String, ProductA[]) and the same input, the call works as expected. The bug seems related to JBXB-96 which is marked as fixed. My purchase() method works with the 1.0.0.GA version of jboss-xml-binding (which was included with jboss 4.2.1.GA, jbossws-1.2.1.GA), but fails in 1.0.0.SP1 (aka CR11) which has the fix for JBXB-96. I looked at the test case created for this bug (org.jboss.test.xml.XsiTypeUnitTestCase). In that test, the collection of objects is the only content of the message. I added a test case to add a wrapper object with a member appearing before the collection. That testcase fails in the same way as my webservice; only the last element of the collection appears in the parent object. -- 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

17 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1829) Remove workaround for google directory lookup bug

by Emanuel Muckenhuber (JIRA)

Remove workaround for google directory lookup bug ------------------------------------------------- Key: JBPORTAL-1829 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1829 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.6.3 Final Reporter: Emanuel Muckenhuber Assigned To: Emanuel Muckenhuber Fix For: 2.6.4 Final Check if the raw text filter workaround for the google widget directory lookup can be removed. The issue is that the rss feed returns an invalid xml document with elements like: <ghapi:category>Fun & Games</ghapi:category> http://www.google.com/ig/directory?synd=jboss&output=rss&num=11&lang=en&c... http://www.google.com/ig/directory?synd=jboss&output=rss&num=11&lang=en&c... -- 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

17 years, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1816) abillity to create profile at registration

by Andrew Oliver (JIRA)

abillity to create profile at registration ------------------------------------------- Key: JBPORTAL-1816 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1816 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.6.3 Final, Identity-1.0.1 Reporter: Andrew Oliver Presently the user has the ability to register, then after logging in they create a profile. At many places that portal will be used registration and initial profile creation are the same. The JSF screens should be reworked to allow the profile fields to appear at registration per a setting. The user module/registration pieces would need to allow profile creation by a not yet logged in user when in the registration process. -- 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

17 years, 11 months

3
20
0 / 0

[JBoss JIRA] Created: (JGRP-528) NAKACK: spurious retransmission requests

by Bela Ban (JIRA)

NAKACK: spurious retransmission requests ----------------------------------------- Key: JGRP-528 URL: http://jira.jboss.com/jira/browse/JGRP-528 Project: JGroups Issue Type: Task Affects Versions: 2.5 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 Every now and then, spurious retransmission requests are received: NAKACK.handleXmitReq(): (requester=192.168.5.2:4397, local_addr=192.168.5.2:4393) message 192.168.5.2:4393::600 not found in retransmission table of 192.168.5.2:4393: [650 : 1050 (1100) (size=x, missing=0, highest stability=650)] It turns out that message #600 *was* actually retransmitted correctly, but the retransmission timer was cancelled too late, so that we got 1 or 2 spurious retransmit requests for the same message. This doesn't happen very frequently, and only under heavy load (e.g. 8 nodes, every node sends 5M 5K messages with 500 threads). Note that this issue DOES NOT LEAD TO INCORRECT 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

17 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4083) Ejb timers fire before the ear completely deploys

by Vadim Kopichenko (JIRA)

Ejb timers fire before the ear completely deploys ------------------------------------------------- Key: JBAS-4083 URL: http://jira.jboss.com/jira/browse/JBAS-4083 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2, Scheduling/Timers Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA Environment: WinNT, Sun JDK 1.5 Reporter: Vadim Kopichenko Assigned To: Scott M Stark Consider the following usecase. The is an ear containing several ejb modules. One of them has a ejb2.1 timed cmp entity bean. If the timer associated with the bean fires during application deployment unexpected errors happen, cause other beans could be not already deployed. This breaks application logic. The problem happens both while server starts/stops and while hot ear's redeployment. It would be much better if timers began to fire after the application had completely deployed. I've also experienced a similar problem with undeployment. Timer code was executed about a half of second after the undeployment had begun. Several ejb modules had been already undeployed by that moment. I guess that timer actually fired exactly before the undeployment had begun but the ejbTimeout executed later due to threads syncronization issue. Please, try also to investigate if this can be avoided. PS Some kind of patch or workaround for 4.0.5 (or even a hint about how this can be fixed) would be greatly appreciated. -- 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

17 years, 11 months

4
3
0 / 0

[JBoss JIRA] Created: (JBWEB-84) Class Cast Exception - when using CometProcessor - Jboss 4.2.0

by Vali Dumitru (JIRA)

Class Cast Exception - when using CometProcessor - Jboss 4.2.0 -------------------------------------------------------------- Key: JBWEB-84 URL: http://jira.jboss.com/jira/browse/JBWEB-84 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Environment: Windows Reporter: Vali Dumitru Assigned To: Mladen Turk I have a servlet that implements CometProcessor interface. Whenever I try to access it I get : java.lang.ClassCastException: org.jboss.web.tomcat.filters.ReplyHeaderFilter at org.apache.catalina.core.ApplicationFilterChain.internalDoFilterEvent(ApplicationFilterChain.java:398) at org.apache.catalina.core.ApplicationFilterChain.doFilterEvent(ApplicationFilterChain.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:227) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:896) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:701) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2031) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) What is this? Is there a workaround? -- 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

17 years, 11 months

2
2
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 2008