March 2007 - jboss-jira - Jboss List Archives

[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, 3 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, 3 months

4
20
0 / 0

[JBoss JIRA] Created: (JBAS-4254) Client read timeout setting wanted for HTTP Invoker

by Anders Welen (JIRA)

Client read timeout setting wanted for HTTP Invoker ---------------------------------------------------- Key: JBAS-4254 URL: http://jira.jboss.com/jira/browse/JBAS-4254 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.3 SP1 Reporter: Anders Welen Priority: Minor There is no read timeout setting to prevent client threads from hanging while using the HTTP Invoker. A quick fix (if you are using SUN JVM) is to use the parameter "-Dsun.net.client.defaultReadTimeout=60000". The problem with this solution is that it affects all connection, not just the HTTPInvoker. A solution that works (if Java 5 is used) is to add a call to the method "setReadTimeout(xxx)" on the "conn" variable in the method "invoke()" in "org.jboss.invocation.http.interfaces.Util". (The same problem exists with the standard JRMP Invoker aswell. It's just the Pooled Invoker that has a read timeout) -- 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, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-324) Build.xml in testsuite directory doesn't support multiple JVM argument

by Sunny Chan (JIRA)

Build.xml in testsuite directory doesn't support multiple JVM argument ---------------------------------------------------------------------- Key: JBBUILD-324 URL: http://jira.jboss.com/jira/browse/JBBUILD-324 Project: JBoss Build System Issue Type: Feature Request Components: Targets and Tasks Affects Versions: Repository Build head, Repsository Build Branch_4_0 Environment: Any Reporter: Sunny Chan Priority: Minor We are using the JBoss unit test as part of our JVM verification testsuite. We wanted to be able to invoke tests with multiple JVM options, but it didn't work. If you set parameters via build.sh -Djunit.vm.options with multiple paramters (e.g. -Djunit.vm.options="-d64 -verbose:gc"), it will fail with unrecongized option error. The problem is that in testsuite/build.xml, the junit.vm.options is passed onto junit ant task via <jvmarg value> tag rather then <jvmarg line> tag. The jvmarg line allows multiple JVM options exist in one line. Once I replace all instance of <jvmarg value="${junit.jvm.options}"/> with <jvmarg line="${junit.jvm.options}"/> then the problem goes away. I can provide a patch for this if you want - but I don't know the rules on patches (whether I need to be cleared for contribution) so let me know if you want that. -- 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, 3 months

4
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-930) Simplify use of @CacheConfig

by Brian Stansberry (JIRA)

Simplify use of @CacheConfig ---------------------------- Key: EJBTHREE-930 URL: http://jira.jboss.com/jira/browse/EJBTHREE-930 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: AS 4.2.0 CR1 Reporter: Brian Stansberry Assigned To: Brian Stansberry There are two separate @CacheConfig impls -- one for the simple cache and one for the clustered. We should support something like: @Stateful @org.jboss.annotation.ejb.cache.simple.CacheConfig(maxSize=200000, idleTimeoutSeconds=500) @Remote(Test.class) public class TestBean implements Test..... where clustering is enabled via <clustered>true</clustered> in jboss.xml. Similarly, @Stateful @org.jboss.annotation.ejb.cache.tree.CacheConfig(maxSize=200000, idleTimeoutSeconds=500, replicationIsPassivation=false) @Remote(Test.class) public class TestBean implements Test..... where clustering is disabled via <clustered>false</clustered> in jboss.xml. Basically, the StatefulCache impls should check for the existence of the other @CacheConfig if the standard one isn't present. Then use the common values between the two, and the default values for any missing configurations (e.g. replicationIsPassivation). Probably the @CacheConfig annotations themselves as well as the impls should be refactored into a type hierarchy. -- 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, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-931) ejb-link with relative path not working

by Carlo de Wolf (JIRA)

ejb-link with relative path not working --------------------------------------- Key: EJBTHREE-931 URL: http://jira.jboss.com/jira/browse/EJBTHREE-931 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Fix For: EJB 3.0 RC11 - FD 12:44:55,904 INFO [MCKernelAbstraction] installing bean: jboss.j2ee:ear=ejb3_bb_stateful_basic.ear,jar=ejb3_bb_stateful_basic_ejb.jar,name=RemoteCalculatorBean,service=EJB3 with dependencies: 12:44:59,748 INFO [EJBContainer] STARTED EJB: com.sun.ts.tests.ejb30.bb.session.stateful.basic.RemoteCalculatorBean ejbName: RemoteCalculatorBean 12:44:59,995 WARN [DeploymentEjbResolver] can't find a deployment for path '' of ejb link '#RemoteCalculatorBean' 12:44:59,996 WARN [EJBHandler] IGNORING DEPENDENCY: unable to find <ejb-ref> of interface com.sun.ts.tests.ejb30.bb.session.stateful.basic.StatefulRemoteCalculator and ejbLink of ejb3_bb_stateful_basic_ejb.jar#RemoteCalculatorBean in application-client.xml of ejb3_bb_stateful_basic_client it might not be deployed yet12:45:00,022 INFO [MCKernelAbstraction] installing bean: jboss.j2ee:ear=ejb3_bb_stateful_basic.ear,jar=ejb3_bb_stateful_basic_client.jar,name=ejb3_bb_stateful_basic_client,service=EJB3 with dependencies: 12:45:00,256 WARN [DeploymentEjbResolver] can't find a deployment for path '' of ejb link '#RemoteCalculatorBean' 12:45:00,258 ERROR [AbstractKernelController] Error installing to Start: name=jboss.j2ee:ear=ejb3_bb_stateful_basic.ear,jar=ejb3_bb_stateful_basic_client.jar,name=ejb3_bb_stateful_basic_client,service=EJB3 state=Create java.lang.RuntimeException: Failed to populate ENC: env/ejb/RemoteCalculatorBean global jndi name was null -- 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, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-910) AllowedSuffixes in the deployer has inverted logic

by Carlo de Wolf (JIRA)

AllowedSuffixes in the deployer has inverted logic -------------------------------------------------- Key: EJBTHREE-910 URL: http://jira.jboss.com/jira/browse/EJBTHREE-910 Project: EJB 3.0 Issue Type: Bug Environment: trunk Reporter: Carlo de Wolf Fix For: EJB 3.0 RC11 - FD Specifying AllowedSuffixes on the EJB3 deployer actually makes it ignore those and pick up the others. -- 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, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-893) Set hibernate.session_factory_name to an appropriate default if the user don't

by Emmanuel Bernard (JIRA)

Set hibernate.session_factory_name to an appropriate default if the user don't ------------------------------------------------------------------------------ Key: EJBTHREE-893 URL: http://jira.jboss.com/jira/browse/EJBTHREE-893 Project: EJB 3.0 Issue Type: Feature Request Reporter: Emmanuel Bernard Fix For: EJB 3.0 RC11 - FD This is useful for clustering http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4017398#4017398 -- 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, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-861) Dependencies should be registered using a canonical name

by Carlo de Wolf (JIRA)

Dependencies should be registered using a canonical name -------------------------------------------------------- Key: EJBTHREE-861 URL: http://jira.jboss.com/jira/browse/EJBTHREE-861 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC9 - Patch 1 Reporter: Carlo de Wolf Priority: Critical Fix For: EJB 3.0 RC10 - FD Tip from Adrian: Why don't you just fix it like the ServiceMetaData does when it doesn't know whether it is dealing with a bean name or ObjectName? String dependency = ... try { ObjectName on = new ObjectName(dependency); dependency = on.getCanonicalName(); } catch (MalformedObjectName ignored) { // Not an object 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

18 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-811) Create a new set of EJB3 deployers

by Carlo de Wolf (JIRA)

Create a new set of EJB3 deployers ---------------------------------- Key: EJBTHREE-811 URL: http://jira.jboss.com/jira/browse/EJBTHREE-811 Project: EJB 3.0 Issue Type: Feature Request Reporter: Carlo de Wolf Priority: Critical The current EJB3 deployers need to be refactored to be more in line with the VDF. This should make it possible to augment metadata from other sources (EAR, Profile etc). - EJB3ParsingDeployer : parses the xml to create metadata - EJB3JBossParsingDeployer: parses the jboss-xml to augment the metadata - EJB3ScanningDeployer: scan annotations to augments the metadata -- 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, 4 months

3
11
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 March 2007