June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-142) Determine binaries

by Brian Stansberry (JIRA)

Determine binaries ------------------ Key: JBCLUSTER-142 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-142 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Need to determine what binaries should be built. Projects like Remoting want a lightweight binary, so we may need to create more than one. -- 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

18 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-143) Create initial release schedule

by Brian Stansberry (JIRA)

Create initial release schedule ------------------------------- Key: JBCLUSTER-143 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-143 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Analyze when things need to be done so they can be integrated into dependent projects. -- 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

18 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1466) customizable error page in the portlet that threw the exception

by William DeCoste (JIRA)

customizable error page in the portlet that threw the exception --------------------------------------------------------------- Key: JBPORTAL-1466 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1466 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.CR2 Reporter: William DeCoste Assigned To: Julien Viet Feature request from Intuit Feature: For error handing, the portlet should be able to render a customizable error page in the portlet that threw the exception. This feature would be something similar to the error-page tag in web.xml. Currently JBoss Portal provides a way to either hide the portlet that has errors or show it with the stack trace or show it with only the error message. But there is no way where the developers could customize the contents that appear in the window for the portlet that throws an exception. We had opened case #00015844 about not being able to use web.xml error-page tag with JBoss portal applications. The provided solution about catching the specific exception in the render method does not work as it is not customizable & too tied up with the portlet class code. And as you might be aware about the WAP function - someone using the WAP application components will not be able to customize it according to their requirements. We know that the portlet standard doesn't specify what to do, and we're just trying to have it behave as much like a regular web application in lieu of something being in the standard. -- 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

18 years, 6 months

4
13
0 / 0

[JBoss JIRA] Created: (JBAS-3410) VDF Deployer migration tasks

by Scott M Stark (JIRA)

VDF Deployer migration tasks ---------------------------- Key: JBAS-3410 URL: http://jira.jboss.com/jira/browse/JBAS-3410 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Deployment services Reporter: Scott M Stark Assigned To: Dimitris Andreadis Priority: Blocker Fix For: JBossAS-5.0.0.Beta The deployers need to be migrated to the new VDF framework: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5DeploymentFramework The subtasks map to the deployers needing to be migrated. -- 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

18 years, 6 months

3
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-718) PojoCache TxLockInterceptor needs to release the lock node as well

by Ben Wang (JIRA)

PojoCache TxLockInterceptor needs to release the lock node as well ------------------------------------------------------------------ Key: JBCACHE-718 URL: http://jira.jboss.com/jira/browse/JBCACHE-718 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Priority: Minor Fix For: 2.0.0 Currently, in TxLockInterceptor, I achieve the node lock by applying explicitly a cache.put(). It has two drawbacks: 1) It explicit going to insert a value to that node 2) Needs to do a remove when it is done. Not much can be done re: 1 now, but we should do 2, alhtough it will degrade the performance further. -- 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

18 years, 6 months

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-754) RPC return values to use a marshaller as well

by Manik Surtani (JIRA)

RPC return values to use a marshaller as well --------------------------------------------- Key: JBCACHE-754 URL: http://jira.jboss.com/jira/browse/JBCACHE-754 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.4.0, 2.0.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0 Currently, all RPC calls go through the VersionAwareMarshaller which is responsible for efficiently marshalling JBC internal objects as well as user objects using JBoss Serialization. Return values and exceptions, on the other hand, are marshalled/unmarshalled using JGroups' Util.{to|from}ByteBuffer() which uses standard object serialization. The problems here are twofold: 1) Relatively inefficient (in speed as well as byte array size) marshalling/unmarshalling for return values 2) Potential class loader problems Most RPC calls in JBoss Cache do not have return values so this is not a problem that comes up often, but certain features (clustered cache loader, data gravitation in buddy replication) rely on return values. The solution to this problem is to be able to register a marshaller with the JGroups RPCDispatcher for return values (and exceptions) as well as for the RPC calls themselves. -- 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

18 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-788) Optimistic locking should not REQUIRE transactions!

by Manik Surtani (JIRA)

Optimistic locking should not REQUIRE transactions! --------------------------------------------------- Key: JBCACHE-788 URL: http://jira.jboss.com/jira/browse/JBCACHE-788 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.4.0, 1.3.0, 2.0.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0 Makes things simpler. TXs are only used so transaction workspaces can be stored in a transaction entry. This workspace can just as easily be stored in ThreadLocal for non-tx calls (that just have the lifespan of a single invocation). This will: 1) Make things a LOT quicker since we don't need 2PC for all calls. 2) Make the TxInterceptor a lot simpler 3) Allow the use of Opt Locking without a TM -- 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

18 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-932) Implicit lock ownership check in UnversionedNode

by Manik Surtani (JIRA)

Implicit lock ownership check in UnversionedNode ------------------------------------------------ Key: JBCACHE-932 URL: http://jira.jboss.com/jira/browse/JBCACHE-932 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA2 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.BETA2 This will involve read and write DIRECT methods on UnversionedNode to check whether the calling thread has acquired the necessary locks, else throw a lock exception. This will ensure proper concurrent access to the Node, even when not going through the interceptor stack. -- 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

18 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4148) Replace Gjt code used in the ejb 2.x validation phase

by Fernando Nasser (JIRA)

Replace Gjt code used in the ejb 2.x validation phase ----------------------------------------------------- Key: JBAS-4148 URL: http://jira.jboss.com/jira/browse/JBAS-4148 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Fernando Nasser Fix For: JBossAS-4.2.1.CR1 The JBossAS thirdpart-build.xml grabs a <componentref name="gjt-jpl-util" version="1.0"/> from repository.jboss.com However, the Gjt project has never released a 1.0 version, only a 0.6 version for the Linffors utils and the jpl_util_0_6 is the only tag in their CVS. So, what is the meaning for version 1.0? The CVS tip? Also, what is marked as gjt-jpl-util also contains gjt-jpl-pattern, and the latest CVS tag for that is: jpl-pattern_0_3_b (0.3 beta perhaps) Besides, there is a warning in the pattern source directory: "Untagged files may be (and probably are) in an unstable state and might not compile. If you want something that works, checkout with tags. You have been warned. :) -- Juha" Here, for the record, is Scott's opinion: Scott M Stark wrote: > This is some ancient code used only in the ejb 2.x validation phase. It > has not been touched in something like 5 years. Either we need to > replace it or pull together some code that makes up a usable release. -- 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

18 years, 6 months

4
20
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-177) Merge the unified metadata work

by Scott M Stark (JIRA)

Merge the unified metadata work ------------------------------- Key: JBMICROCONT-177 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-177 Project: JBoss MicroContainer Issue Type: Task Components: MetaData Reporter: Scott M Stark Need to merge the unified metadata work so we can start integrate it into the deployers. -- 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

18 years, 6 months

5
4
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 June 2007