July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5749) tcnative-1.dll version 1.1.14 not recognized in %JBOSS_HOME%\bin\native

by Juergen Zimmermann (JIRA)

tcnative-1.dll version 1.1.14 not recognized in %JBOSS_HOME%\bin\native ----------------------------------------------------------------------- Key: JBAS-5749 URL: http://jira.jboss.com/jira/browse/JBAS-5749 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.CR1 Environment: JBoss 5.0.0.CR1, JDK 6u10beta, WinXP SP2 Reporter: Juergen Zimmermann tcnative-1.dll version 1.1.14 and openssl.exe are available in %JBOSS_HOME%\bin\native However, server.log shows this log entry: 2008-07-09 17:28:38,756 INFO [org.apache.catalina.core.AprLifecycleListener] (main) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: C:/Programme/jboss/bin/native -- 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

1
2
0 / 0

[JBoss JIRA] Closed: (JBAOP-509) Connect the graph to the rest of AOP code

by Flavia Rainone (JIRA)

[ https://jira.jboss.org/jira/browse/JBAOP-509?page=com.atlassian.jira.plug... ] Flavia Rainone closed JBAOP-509. -------------------------------- Resolution: Done > Connect the graph to the rest of AOP code > ----------------------------------------- > > Key: JBAOP-509 > URL: https://jira.jboss.org/jira/browse/JBAOP-509 > Project: JBoss AOP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Flavia Rainone > Assignee: Flavia Rainone > > This task consists in using the joinpoint graph during JBoss AOP execution. -- 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

18 years

1
0
0 / 0

[JBoss JIRA] Closed: (JBAOP-502) Joinpoint Graph

by Flavia Rainone (JIRA)

[ https://jira.jboss.org/jira/browse/JBAOP-502?page=com.atlassian.jira.plug... ] Flavia Rainone closed JBAOP-502. -------------------------------- Resolution: Done Currently this feature is implemented in the JoinpointGraph branch only. > Joinpoint Graph > --------------- > > Key: JBAOP-502 > URL: https://jira.jboss.org/jira/browse/JBAOP-502 > Project: JBoss AOP > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.CR7 > Reporter: Flavia Rainone > Assignee: Flavia Rainone > > Implement the joinpoint graph algorithm for dynamic AOP -- 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

18 years

1
0
0 / 0

[JBoss JIRA] Commented: (JBAOP-509) Connect the graph to the rest of AOP code

by Flavia Rainone (JIRA)

[ https://jira.jboss.org/jira/browse/JBAOP-509?page=com.atlassian.jira.plug... ] Flavia Rainone commented on JBAOP-509: -------------------------------------- For now, I am skipping the addition of proxy infos because they are created in an inconsistent state. > Connect the graph to the rest of AOP code > ----------------------------------------- > > Key: JBAOP-509 > URL: https://jira.jboss.org/jira/browse/JBAOP-509 > Project: JBoss AOP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Flavia Rainone > Assignee: Flavia Rainone > > This task consists in using the joinpoint graph during JBoss AOP execution. -- 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

18 years

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3911) Default max-pool-size in DataSource configuration

by Shrinivas Joshi (JIRA)

Default max-pool-size in DataSource configuration ------------------------------------------------- Key: JBAS-3911 URL: http://jira.jboss.com/jira/browse/JBAS-3911 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.5.GA Reporter: Shrinivas Joshi Assigned To: Weston Price In *-[xa]-ds.xml if max-pool-size is not specified and only min-pool-size is specified then max-pool-size should be set = min-pool-size whereas it defaults to 20 rendering min-pool-size setting of no use. -- 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
8
0 / 0

[JBoss JIRA] Created: (JBCL-19) Add recursion filter to Module::visit

by Ales Justin (JIRA)

Add recursion filter to Module::visit ------------------------------------- Key: JBCL-19 URL: https://jira.jboss.org/jira/browse/JBCL-19 Project: JBoss ClassLoader Issue Type: Feature Request Components: Modules Affects Versions: JBossCL.2.0.0.Beta12 Reporter: Ales Justin Assignee: Ales Justin Fix For: JBossCL.2.0.0.CR1 See forum thread for more 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

18 years

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1116) Clustered container sees requests during shutdown

by Brian Stansberry (JIRA)

Clustered container sees requests during shutdown ------------------------------------------------- Key: EJBTHREE-1116 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1116 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: AS 4.2.2.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=123677 -- during undeploy the cache is being asked for beans after it has already gone into cleanup. It should not be exposed to requests at this point. A couple points: 1) StatefulContainer.stop() does this: if (cache != null) cache.stop(); super.stop(); Basically the cache is stopped before anything else. 2) The HA versions of the old detached invokers included this kind of logic in invoke(): HATarget target = (HATarget)beanMap.get(invocation.getObjectName()); if (!target.invocationsAllowed ()) throw new GenericClusteringException(GenericClusteringException.COMPLETED_NO, "invocations are currently not allowed on this target"); .... else continue on and handle call An HA proxy will catch the GenericClusteringException and fail over. There is no equivalent interceptor in EJB3. In the container stop() methods there is a usage of Dispatcher.singleton.unregisterTarget(...) which will lead to an exception being thrown if a call comes in for the container, and an HA proxy will catch that exception and fail over. So, adding an interceptor to check the HATarget *may* not be necessary, if we are sure that Dispatcher.singleton.unregisterTarget(...) is always called very early in the stop() process. -- 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
5
0 / 0

[JBoss JIRA] Created: (JBAS-5781) Use READ_COMMITTED for clustered entity cache

by Brian Stansberry (JIRA)

Use READ_COMMITTED for clustered entity cache --------------------------------------------- Key: JBAS-5781 URL: https://jira.jboss.org/jira/browse/JBAS-5781 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, EJB3 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.0.0.CR2 In the standard configs for 2nd level caching using JBC2, switch to READ_COMMITTED from REPEATABLE_READ for the pessimistic locking cache configs. Add a couple new configs "pessimistic-entity-repeatable" and "pessimistic-shared-repeatable" for the occasional use case that needs R_R semantics with pessimistic locking. -- 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

18 years

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1757) Update workflow chapter as it doesn't take into account the fact that the workflow service has been extracted... Should also document how to use the service in portlets.

by Chris Laprun (JIRA)

Update workflow chapter as it doesn't take into account the fact that the workflow service has been extracted... Should also document how to use the service in portlets. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBPORTAL-1757 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1757 Project: JBoss Portal Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Chris Laprun -- 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

2
5
0 / 0

[JBoss JIRA] Created: (JGRP-701) Investigate making FD_ALL the default failure detection protocol

by Bela Ban (JIRA)

Investigate making FD_ALL the default failure detection protocol ---------------------------------------------------------------- Key: JGRP-701 URL: http://jira.jboss.com/jira/browse/JGRP-701 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.7 Replacing FD, so the new combo would be FD_SOCK and FD_ALL. The advantage of FD_ALL is that we detect *many* concurrent failures much faster than FD. E.g if we have A,B,C,D,E and B and C fail, and FD.timeout=1000 and FD.max_tries=3, FD_ALL.timeout=3000 and FD_ALL.interval=1000, then: FD will take timeout * max_tries ms to detect the death of B and the same for C, so a total of 6 seconds. FD_ALL will take timeout ms to detect both failures, so a total of 3 seconds. FD_ALL is also much simpler in its implementation, therefore simpler to verify for correctness -- 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

2
6
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 2008