July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-379) function with another drools function call won't compile (either with eclipse compiler or janino)

by Thierry R (JIRA)

function with another drools function call won't compile (either with eclipse compiler or janino) ------------------------------------------------------------------------------------------------- Key: JBRULES-379 URL: http://jira.jboss.com/jira/browse/JBRULES-379 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.1 Environment: Debian linux JDK 5 Reporter: Thierry R Assigned To: Mark Proctor function with another drools function call won't compile (either with eclipse compiler or janino) with the error msg : "Function Compilation error " I wrote a DroolsHelper class to work around. -- 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

4
6
0 / 0

[JBoss JIRA] Assigned: (JBMESSAGING-265) Soak tests

by Clebert Suconic (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-265?page=all ] Clebert Suconic reassigned JBMESSAGING-265: ------------------------------------------- Assignee: Clebert Suconic > Soak tests > ---------- > > Key: JBMESSAGING-265 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-265 > Project: JBoss Messaging > Issue Type: Task > Reporter: Ovidiu Feodorov > Assigned To: Clebert Suconic > Fix For: 1.4.0.CR1 > > > A test that runs long enough and sends a significant number of messages into the server; used to detect memory leaks and failure under load -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4527) Cookie and Header information Lost while processing servlets

by Dick Weisinger (JIRA)

Cookie and Header information Lost while processing servlets ------------------------------------------------------------ Key: JBAS-4527 URL: http://jira.jboss.com/jira/browse/JBAS-4527 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-4.2.0.GA Environment: Windows XP; ColdFusion 8 Reporter: Dick Weisinger I'm seeing different behavior using JSP and CFMs with different versions of JBoss. At the top of my JSP page I include: <jsp:include page="../../../app/Application.cfm"/> Application.cfm tries to set cookie and header data: <cfheader name="CP" value="NOI DSP COR NID ADMa OPTa OUR NOR"> .... <cfcookie name="MyCookie" value="#NewDataforCookie#" expires="never"> Using JBoss version 4.0.5GA the header information and cookies are correctly set. But when I deploy the same war file with JBoss 4.2.0, both header and cookie information gets lost. Can this behavior in version 4.2.0 be modified via a configuration change? Is there a workaround? ------------------------------------------------------------------------------ How to reproduce: Use JBoss 4.2.0. Deploy Cold Fusion war on JBoss. Create a JSP page and put at the top of it: <jsp:include page="../../../app/Application.cfm"/> In the referenced Application.cfm file set the following: <cfheader name="CP" value="NOI DSP COR NID ADMa OPTa OUR NOR"> <cfcookie name="MyCookie" value="ArbitraryData" expires="never"> In your browser, delete your cookies. Open the JSP file. Check for the cookie and header information. For us, it is getting lost. -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1552) in google gadgets preferences displayName is not used for configuration

by Boleslaw Dawidowicz (JIRA)

in google gadgets preferences displayName is not used for configuration ----------------------------------------------------------------------- Key: JBPORTAL-1552 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1552 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Widget Affects Versions: 2.6 Final Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Fix For: 2.6.1 Final, 2.8 Final In AdminPortlet when configuring Google Widget preferences 'displayName' attribute should be displayed - not 'name' -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-988) error in querydescriptor dumper for drl

by Fernando Meyer (JIRA)

error in querydescriptor dumper for drl --------------------------------------- Key: JBRULES-988 URL: http://jira.jboss.com/jira/browse/JBRULES-988 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.MR3, 4.0.0.MR2, 3.1-m1 Reporter: Fernando Meyer Assigned To: Fernando Meyer Fix For: 4.0.0.MR4, FUTURE, 4.0.0.MR3, 4.0.0.MR2 -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-987) Wrong condition in not dumper for Drl

by Fernando Meyer (JIRA)

Wrong condition in not dumper for Drl -------------------------------------- Key: JBRULES-987 URL: http://jira.jboss.com/jira/browse/JBRULES-987 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.MR3, 4.0.0.MR2 Reporter: Fernando Meyer Assigned To: Fernando Meyer Fix For: 4.0.0.MR4, FUTURE -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1123) Non-streaming state transfer failures not properly handled

by Brian Stansberry (JIRA)

Non-streaming state transfer failures not properly handled ---------------------------------------------------------- Key: JBCACHE-1123 URL: http://jira.jboss.com/jira/browse/JBCACHE-1123 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 2.0.0.CR3 Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.0.0.CR4 I'm noticing spurious WARN messages in the logs from JGroups when caches do partial state transfers and the cache being requested doesn't have the target node available: WARN [org.jgroups.protocols.pbcast.STATE_TRANSFER] state received from 192.168.1.164:4655 is null, will return null state to application Looking at the JBC state transfer code, particularly StateTransferManager.getState(ObjectOutputStream out, Fqn fqn, long timeout, boolean force, boolean suppressErrors), the apparent intent is for a boolean 'false' and a CacheException to be written to the stream, serialized, and returned to the requestor. The CacheException is also thrown. This is breaking in CacheImpl.MessageListenerAdaptor.getState() and getState(String): try { ExposedByteArrayOutputStream baos = new ExposedByteArrayOutputStream(16 * 1024); out = new MarshalledValueOutputStream(baos); getStateTransferManager().getState(out, Fqn.fromString(sourceRoot), configuration.getStateRetrievalTimeout(), true, true); result = baos.getRawBuffer(); } catch (Throwable t) { stateProducingFailed(t); } finally { Util.close(out); } return result; The CacheException is thrown from StateTransferManager.getState(). Therefore "result = baos.getRawBuffer();" is never invoked. Therefore the returned state is null, leading to the WARN on the recipient. This seems contrary to the intent to propagate the boolean + exception to the recipient. -- 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
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1124) Cache tutorial talks about doing a Node.hasChild(Object name) but this method doesnt exist

by Manik Surtani (JIRA)

Cache tutorial talks about doing a Node.hasChild(Object name) but this method doesnt exist ------------------------------------------------------------------------------------------ Key: JBCACHE-1124 URL: http://jira.jboss.com/jira/browse/JBCACHE-1124 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR3 Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Minor Fix For: 2.0.0.CR4 Fix the API to allow for this method -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBPM-1013) Logging out and back in seems to render an error.

by Micah Modell (JIRA)

Logging out and back in seems to render an error. ------------------------------------------------- Key: JBPM-1013 URL: http://jira.jboss.com/jira/browse/JBPM-1013 Project: JBoss jBPM Issue Type: Bug Components: Web Interface Affects Versions: jBPM jPDL 3.2.1 Environment: Fedora Core 6 + Firefox 1.5.0.12 + Sun Java 1.5.0.12 Reporter: Micah Modell Assigned To: Tom Baeyens If you log in and leave for about fifteen minutes or so, then return and attempt to log oout and back in as another user, you get the following (ugly) jsp error: -------------- HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: viewId:/sa/identities.jsf - View /sa/identities.jsf could not be restored. javax.faces.webapp.FacesServlet.service(FacesServlet.java:249) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) root cause javax.faces.application.ViewExpiredException: viewId:/sa/identities.jsf - View /sa/identities.jsf could not be restored. com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180) com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248) com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs. Apache Tomcat/5.5.17 -------------- and the following stack trace on the console: -------------- javax.faces.application.ViewExpiredException: viewId:/sa/identities.jsf - View /sa/identities.jsf could not be restored. at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:180) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:595) -- 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

3
2
0 / 0

[JBoss JIRA] Created: (JBFORUMS-243) safeClose method never more used in Portal common project

by Luca Stancapiano (JIRA)

safeClose method never more used in Portal common project --------------------------------------------------------- Key: JBFORUMS-243 URL: http://jira.jboss.com/jira/browse/JBFORUMS-243 Project: JBoss Forums Issue Type: Bug Components: Forum Model Layer Affects Versions: 1.0.1 RC Environment: forums taken at http://anonsvn.labs.jboss.com/labs/jbossforums/branches/forums101P26 since 12 jun 2007 portal taken at http://anonsvn.jboss.org/repos/portal/trunk since 12 jun 2007 Reporter: Luca Stancapiano Assigned To: Ryszard Kozmik Fix For: 1.0.1 RC Attachments: TCCLXProperties.java hi ryszak....it seems that safeClose(Object in) method of org.jboss.portal.common.util.Tools of Portal 2.6 common project is never more used. I rewrote org.jboss.portlet.forums.properties.TCCLXProperties class : row 85 finally { Tools.safeClose(in); } so: finally { in.close(); } bye -- 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
5
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 July 2007