October 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-7257) org.jboss.test.deployers.seam.test.Seam*ExampleUnitTestCase

by Shelly McGowan (JIRA)

org.jboss.test.deployers.seam.test.Seam*ExampleUnitTestCase ----------------------------------------------------------- Key: JBAS-7257 URL: https://jira.jboss.org/jira/browse/JBAS-7257 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Shelly McGowan Assignee: Shelly McGowan Fix For: JBossAS-5.2.0.Beta1 SEAM examples failing to deploy with the following error when processing jars in WARs WEB-INF/lib directory: 2009-09-14 13:01:27,760 ERROR [org.apache.catalina.startup.TldConfig] (WorkerThread#0[127.0.0.1:59105]) Exception processing JAR at resource path /work/Branch_5_x/build/output/jboss-5.2.0.Beta1/server/all/tmp/3j001-fc2u1g-fzlgnahp-1-fzlgpa1i-ac/jboss-seam-booking.war/WEB-INF/lib/jboss-seam-debug.jar in context /seam-booking java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.jar.JarFile.<init>(JarFile.java:133) at java.util.jar.JarFile.<init>(JarFile.java:97) at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:461) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:301) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4540) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4308) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:321) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:146) at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:462) at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) at org.jboss.web.deployers.WebModule.start(WebModule.java:97) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
11
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2432) PortletRequestDispatcher does not execute 'forward' method during resource request.

by Alexander Smirnov (JIRA)

PortletRequestDispatcher does not execute 'forward' method during resource request. ----------------------------------------------------------------------------------- Key: JBPORTAL-2432 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2432 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Environment: Jboss Portal 2.7 built from http://anonsvn.jboss.org/repos/portal/branches/JBoss_Portal_Branch_2_7 revision 13553 / Jboss AS 4.2.3.GA Reporter: Alexander Smirnov By default, GenericFacesPortlet uses PortletRequestDispatcher.forward method to serve resources during resource requests. The code is: /** * Default resource serving. * <p> * The default implemention of this method is to call a * RequestDispatcher.foward with the ResourceID of the ResourceRequest. * <p> * If no ResourceID is set on the resource URL the default implementation * does nothing. * * @since 2.0 */ public void serveResource(ResourceRequest request, ResourceResponse response) throws PortletException, IOException { if (request.getResourceID() != null) { PortletRequestDispatcher rd = getPortletConfig().getPortletContext().getRequestDispatcher( request.getResourceID()); if (rd != null) rd.forward(request, response); } } Never that code nor custom portletBridge code that uses 'forward' method doesn't work in Jboss Portal but works properly in other Portlet 2.0 implementations. The same PortletRequestDispatcher.forward method works properly during render request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (JBVFS-125) Allow for plugable temp location creation

by Ales Justin (JIRA)

Allow for plugable temp location creation ----------------------------------------- Key: JBVFS-125 URL: https://jira.jboss.org/jira/browse/JBVFS-125 Project: JBoss VFS Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.1.3.SP1 Reporter: Ales Justin Assignee: Ales Justin Fix For: 2.2.0.Alpha Users should be able to provide their own mechanism of temp location creation. See the forum post for the actual use case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7308) wrong attributes in templates for persistence manager and post office configuration

by testrot (JIRA)

wrong attributes in templates for persistence manager and post office configuration ----------------------------------------------------------------------------------- Key: JBAS-7308 URL: https://jira.jboss.org/jira/browse/JBAS-7308 Project: JBoss Application Server Issue Type: Quality Risk Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.GA Reporter: testrot The templates for the Persistence Manager MBean and Messaging Post Office MBean seem to be wrong (xyz-persistence-service.xml). For example the template for MS SQL (..\docs\examples\jms\mssql-persistence-service.xml) contains the attributes "DetectDuplicates" and "IDCacheSize" in the configuration section for the persistence manager. Shouldn't these attributes belong to the Post Office configuration? At least the "JBoss Messaging 1.4 User's Guide" page 33 suggests this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-1946) Deserializing a KnowledgeBase object throws a java.io.EOFException

by Simon Kelly (JIRA)

Deserializing a KnowledgeBase object throws a java.io.EOFException ------------------------------------------------------------------ Key: JBRULES-1946 URL: https://jira.jboss.org/jira/browse/JBRULES-1946 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.0.M5, 5.0.0.M4 Environment: Ubuntu 8.10 Reporter: Simon Kelly Assignee: Mark Proctor A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file. java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280) at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55) at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49) at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227) at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173) at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83) at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at com.sample.DroolsTest.read(DroolsTest.java:75) at com.sample.DroolsTest.testIO(DroolsTest.java:50) at com.sample.DroolsTest.main(DroolsTest.java:40) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

5
15
0 / 0

[JBoss JIRA] Updated: (JGRP-100) Large-scale JGroups

by Bela Ban (JIRA)

[ https://jira.jboss.org/jira/browse/JGRP-100?page=com.atlassian.jira.plugi... ] Bela Ban updated JGRP-100: -------------------------- Fix Version/s: 2.9 (was: 3.x) > Large-scale JGroups > ------------------- > > Key: JGRP-100 > URL: https://jira.jboss.org/jira/browse/JGRP-100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 2.9 > > > - Run JGroups on hundreds of nodes (either physical, or simulation). > - Determine a protocol stack that can be used for large-scale execution > - Example: > - Coordinator may be SPOF. If coord is hung, messages will be sent, but no new views will > be generated > - Retransmission: retransmit from anyone (not sender, otherwise we have NAK implosion) > - Look at PBCAST -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-1044) UNICAST: use actual retransmission values for timeouts

by Bela Ban (JIRA)

UNICAST: use actual retransmission values for timeouts ------------------------------------------------------ Key: JGRP-1044 URL: https://jira.jboss.org/jira/browse/JGRP-1044 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 In NAKACK, we already have use_stats_for_retransmission. Implement the same in UNICAST: Every AckSenderWindow maintains AVG_XMIT_TIME (a double) which is a rolling average of the retransmission times (diff between sending a message and receiving its ACK). Once we have AVG_XMIT_TIME, we schedule retransmission tasks to be AVG_XMIT_TIME + CONST. CONST should be a few millisconds, but could also be 0. The rolling average should start with an initial value (say 30ms), and then add the diff between sending of a message and reception of its ACK, for each ACK received, divided by the number of values. More recent values should be weighted higher, so we have a decay of values over time. We could make this simple by having a bounded number of values, e.g. the last 1000 values. So, assuming a CONST of 10, if we have a rolling average of 350ms to member B, then we would schedule retransmission of our messages to B to 360ms. If the avg drops down to 30, we'd retransmit in 40. If it increases to 2300, we'd go to 2310 etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBBOOT-109) Port Embedded API and Core to Bootstrap Components

by Andrew Lee Rubinger (JIRA)

Port Embedded API and Core to Bootstrap Components -------------------------------------------------- Key: JBBOOT-109 URL: https://jira.jboss.org/jira/browse/JBBOOT-109 Project: JBoss Bootstrap Issue Type: Task Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger The following components: org.jboss.embedded:jboss-embedded-api org.jboss.embedded:jboss-embedded-core Are ready to graduate from the Embedded groupId. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-7148) Archived war deployment with jars in WEB-INF/lib leads to exploding the jars in tmp folder

by jaikiran pai (JIRA)

Archived war deployment with jars in WEB-INF/lib leads to exploding the jars in tmp folder ------------------------------------------------------------------------------------------ Key: JBAS-7148 URL: https://jira.jboss.org/jira/browse/JBAS-7148 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Environment: Branch_5_x and AS trunk Reporter: jaikiran pai Assignee: Andrew Lee Rubinger Deploying an archived war file in Branch_5_x and trunk, which contains jar files in the WEB-INF/lib folder of the war leads to these jars being exploded to tmp folder too. This results in deployment errors when some tomcat code expects the libraries to be zipped jars. See the reference forum thread for complete details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
3
0 / 0

[JBoss JIRA] Resolved: (JBAS-7100) Exploding vfsmemory:// contents is empty for web deployments

by Andrew Lee Rubinger (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-7100?page=com.atlassian.jira.plug... ] Andrew Lee Rubinger resolved JBAS-7100. --------------------------------------- Resolution: Done Reverted > Exploding vfsmemory:// contents is empty for web deployments > ------------------------------------------------------------ > > Key: JBAS-7100 > URL: https://jira.jboss.org/jira/browse/JBAS-7100 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Reporter: Andrew Lee Rubinger > Assignee: Andrew Lee Rubinger > Fix For: JBossAS-5.2.0.Beta1, JBossAS-6.0.0.Alpha1 > > > The following patch addresses this: > [alrubinger@localhost Branch_5_x]$ svn di server/ > When using an in-memory archive backed by VFS, we're using an "unjar"; this leaves out any RAM-backed resources. Instead explode the contents, regardless of what's behind the virtual abstraction: > Index: server/src/main/org/jboss/web/deployers/AbstractWarDeployer.java > =================================================================== > --- server/src/main/org/jboss/web/deployers/AbstractWarDeployer.java (revision 91204) > +++ server/src/main/org/jboss/web/deployers/AbstractWarDeployer.java (working copy) > -357,7 +357,7 @@ > > VFSDeploymentUnit vfsUnit = (VFSDeploymentUnit)unit; > VirtualFile root = vfsUnit.getRoot(); > - VirtualFile unjared = VFSUtils.unjar(root); > + VirtualFile unjared = VFSUtils.explode(root); > // file was not unjared yet > if (root != unjared) > { > This was exposed by prototyping in EMB-32. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 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-jira October 2009