June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-738) @SecurityDomain should throw Exception if "java:/jaas/..."

by Wolfgang Knauf (JIRA)

@SecurityDomain should throw Exception if "java:/jaas/..." ---------------------------------------------------------- Key: EJBTHREE-738 URL: http://jira.jboss.com/jira/browse/EJBTHREE-738 Project: EJB 3.0 Issue Type: Feature Request Components: EJB3 Extensions Affects Versions: EJB 3.0 RC9 - FD Reporter: Wolfgang Knauf Priority: Minor Security Domains in J2EE 1.4 environment were always specified as "java:/jaas/MySecurityDomain", but the @SecurityDomain requires only "MySecurityDomain". To avoid this trapdoor a simple check "if (value.startsWith ("java:/jaas/") ) throw Exception" would probably avoid some errors in updating from EJB2.1 to EJB3. Same check makes sense for the annotation "<security-domain>" in jboss.xml. -- 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

16 years

2
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-369) Work on a site plugin configuration that follows the jboss.org look and feel.

by Paul Gier (JIRA)

Work on a site plugin configuration that follows the jboss.org look and feel. ----------------------------------------------------------------------------- Key: JBBUILD-369 URL: http://jira.jboss.com/jira/browse/JBBUILD-369 Project: JBoss Build System Issue Type: Feature Request Reporter: Paul Gier Assigned To: Paul Gier Fix For: MavenBuild 2.0 Create a maven skin with the look of the new jboss.org. Figure out how the maven generated sites should be deployed to jboss.org. -- 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

16 years, 1 month

1
8
0 / 0

[JBoss JIRA] Created: (JGRP-520) OOM with RpcDispatcher

by Bela Ban (JIRA)

OOM with RpcDispatcher ---------------------- Key: JGRP-520 URL: http://jira.jboss.com/jira/browse/JGRP-520 Project: JGroups Issue Type: Bug Environment: 1.5.0_10-b03;Sun Microsystems Inc.;mixed mode, sharing;Windows;32 bit JVM Windows Server 2003 Standard x64 Reporter: Bela Ban Assigned To: Bela Ban Priority: Critical Fix For: 2.5 Attachments: SimpleClusterManager.java [from Patrick Eger] Attempting to isolate the problem, I ran into a (probably unrelated) other OutOfMemoryError problem with JGroups 1.5b2. Got an OutOfMemoryError after ~3 minutes of running the attached TestJGroups.java, 3 instances in parallel. Also attached is the stack config and a couple YJP views of the HPROF dump as generated by -XX:+HeapDumpOnOutOfMemoryError. The test is looping single-threaded, calling a remote method via RpcDispatcher every 100 ms which returns a few KB String. Looks like all the memory is retained instances of org.jgroups.stack.IpAddress (~1,000,000 for a ~3 minute run (seems like a lot?)), held by pbcast.NAKACK.sent_msgs. I have the HPROF dump if you need, its about 15 megs zipped so I assumed would not make it through the mail filters. Is this a real OOME or is it a stack configuration/tuning thing? I have used the default UDP config, but with increased thread_pool and oob_thread_pool sizes. Options ----------------------------------------- -agentlib:yjpagent -server -Xmx64m -XX:+HeapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote -Dpeer_cluster_manager.XXXTestClusterXXX.jgroups_config=C:\tmp\testcfg.x ml -- 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

16 years, 1 month

1
7
0 / 0

[JBoss JIRA] Created: (JGRP-279) Move web page from SourceForge to labs.jboss.org

by Bela Ban (JIRA)

Move web page from SourceForge to labs.jboss.org ------------------------------------------------ Key: JGRP-279 URL: http://jira.jboss.com/jira/browse/JGRP-279 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.6 -- 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

16 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4307) Tag file: Variables from outer tags are not available in inner tags

by Wolfgang Knauf (JIRA)

Tag file: Variables from outer tags are not available in inner tags ------------------------------------------------------------------- Key: JBAS-4307 URL: http://jira.jboss.com/jira/browse/JBAS-4307 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.2.0.CR1 Reporter: Wolfgang Knauf Assigned To: Remy Maucherat I created two tag files ("outer" and "inner"), in the jsp "inner" is a nested tag of "outer". In the outer tag file I declare a variable and write it to the jspContext. This variable is available in the jsp, but not in "inner.tag". outer.tag <%@ variable name-given="test" scope="NESTED" %> <% jspContext.setAttribute ("test", "This is a test !", PageContext.PAGE_SCOPE); %> Value before doBody: ${test} <br> <jsp:doBody/> Value after doBody: ${test} <br> inner.tag: Value in inner tag: ${test} <br> test.jsp: <?xml version="1.0" encoding="ISO-8859-1" ?> <%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%> <%@ taglib prefix="test" tagdir="/WEB-INF/tags" %> <html> <body> <test:outer> Value in test.jsp: ${test} <br> <test:inner/> </test:outer> </body> </html> The output is: Value before doBody: This is a test ! Value in test.jsp: This is a test ! Value in inner tag: Value after doBody: This is a test ! The inner tag does not see the attribute. I don't know whether this is a bug or whether the spec forbids this, but I think it should be possible for the inner tag to see the parent variables. A usage sample would be some iterator tag which places the current item in a jspContext variable and the inner tags must be able to access the current item (the variable name is an attribute of the inner tag). I could place the current item in the request scope, but this is much too global. -- 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

16 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBBUILD-387) Add missing md5/sha1 checksums to repository.jboss.org

by Paul Gier (JIRA)

Add missing md5/sha1 checksums to repository.jboss.org ------------------------------------------------------ Key: JBBUILD-387 URL: http://jira.jboss.com/jira/browse/JBBUILD-387 Project: JBoss Build System Issue Type: Task Components: Maven Reporter: Paul Gier Assigned To: Paul Gier Fix For: Maven Build - Maint 2007 Several of the artifacts currently in the repository are missing the maven generated checksums. This causes warning messages to be displayed during builds. These checksums should be generated and added to the repository. -- 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

16 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-3624) <security-domain> setting in deployment descriptor populates @SecurityDomain annotation incorrectly on EJB3 session beans

by David Green (JIRA)

<security-domain> setting in deployment descriptor populates @SecurityDomain annotation incorrectly on EJB3 session beans ------------------------------------------------------------------------------------------------------------------------- Key: JBAS-3624 URL: http://jira.jboss.com/jira/browse/JBAS-3624 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.0.4.GA Reporter: David Green Assigned To: Bill Burke Specifying a <security-domain> in the jboss-app.xml incorrectly sets the @SecurityDomain on EJB3 session beans. In the jboss-app.xml the security domain is specified as follows: <jboss-app> <security-domain>java:/jaas/hch</security-domain> </jboss-app> In Ejb3DescriptorHandler the security-domain is copied directly into the SecurityDomainImpl instance as "java:/jaas/hch", however the @SecurityDomain annotation should be populated with the value "hch" (without the leading "java:/jaas/" prefix). This causes the EJB3 session bean authentication to behave unexpectedly, since the authentication for the bean reverts to the default domain instead of the specified one. The only way I've found to workaround this issue is to specify the @SecurityDomain individually on every session bean in the project. -- 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

16 years, 1 month

5
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-341) ComponentRefGraphLicenseVisitor needs to externalize the repository url

by Scott M Stark (JIRA)

ComponentRefGraphLicenseVisitor needs to externalize the repository url ----------------------------------------------------------------------- Key: JBBUILD-341 URL: http://jira.jboss.com/jira/browse/JBBUILD-341 Project: JBoss Build System Issue Type: Bug Components: JBossBuild Reporter: Scott M Stark ComponentRefGraphLicenseVisitor always looks to URL("http://repository.jboss.com/licenses/") to obtain the license text. This should be looking to the location passed into the project build so that if can be overriden by the local build properties. -- 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

16 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-3997) getManagedConnection retries

by Adrian Brock (JIRA)

getManagedConnection retries ---------------------------- Key: JBAS-3997 URL: http://jira.jboss.com/jira/browse/JBAS-3997 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Reporter: Adrian Brock Assigned To: Weston Price We should add the ability to retry getManagedConnection() when there is a resource exception from the pool. This will allow the ConnectionManagers to be more tolerant of transient failures. I'd suggest two new attributes on the connection manager, with the suggested defaults: <allocate-retry>1</allocate-retry> <allocate-retry-wait-millis>5000</allocate-retry-wait-millis> I also think the connection manager needs a "shutdown" boolean (maintained by start/stop) i.e. so don't wait 5 seconds if we get a resource exception caused by the CM/Pool getting undeployed, e.g. at JBoss shutdown. This would turn into the following *untested* code in BaseConnectionManager2: protected ConnectionListener getManagedConnection(Transaction transaction, Subject subject, ConnectionRequestInfo cri) throws ResourceException { ResourceException failure = null; if (shutdown.get()) throw new ResourceException("The connection manager is shutdown " + jndiName); // First attempt try { return poolingStrategy.getConnection(transaction, subject, cri); } catch (ResourceException e) { failure = e; // Retry? for (int i = 0; i < allocationRetries; ++i) { if (shutdown.get()) throw new ResourceException("The connection manager is shutdown " + jndiName); try { if (allocationWait != 0) wait(allocationWait); return poolingStrategy.getConnection(transaction, subject, cri); } catch (ResourceException e1) { failure = e1; } catch (InterruptedException e1) { JBossResourceException.rethrowAsResourceException("getManagedConnection retry wait was interrupted " + jndiName, e1); } } } // If we get here all retries failed, throw the lastest failure throw failure; } -- 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

16 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-3916) Update source code headers.

by Dimitris Andreadis (JIRA)

Update source code headers. --------------------------- Key: JBAS-3916 URL: http://jira.jboss.com/jira/browse/JBAS-3916 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Other Reporter: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta2 Update the source code headers, like it was done for Branch_4_0 in JBAS-3601 -- 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

16 years, 2 months

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2007