May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1326) images for phalanx theme

by Luca Stancapiano (JIRA)

images for phalanx theme ------------------------ Key: JBPORTAL-1326 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1326 Project: JBoss Portal Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 2.6.Beta1 Environment: any Reporter: Luca Stancapiano Fix For: 2.6.Beta1 Attachments: modifiche.rar hi......don't you think that buttons of phalanx theme are a lot twisted? I send you the correct images for that theme -- 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

19 years, 2 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAS-4418) run.bat should include %PATH% in java.library.path when bin/native exists

by David Richmond (JIRA)

run.bat should include %PATH% in java.library.path when bin/native exists ------------------------------------------------------------------------- Key: JBAS-4418 URL: http://jira.jboss.com/jira/browse/JBAS-4418 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.0.GA Environment: Windows XP, Java 1.5_04 Reporter: David Richmond run.bat says this if exist "%JBOSS_HOME%\bin\native" set PATH=%JBOSS_HOME%\bin\native;%PATH% if exist "%JBOSS_HOME%\bin\native" set JAVA_OPTS=%JAVA_OPTS% -Djava.library.path=%JBOSS_HOME%\bin\native Which removes %PATH% from the java.library.path and thus breaks anything else which has DLLs on the PATH, such as Oracle OCI drivers. -- 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

19 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1033) Clarify usage of DummyTransactionManager in 2.0

by Elias Ross (JIRA)

Clarify usage of DummyTransactionManager in 2.0 ----------------------------------------------- Key: JBCACHE-1033 URL: http://jira.jboss.com/jira/browse/JBCACHE-1033 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Elias Ross Assigned To: Manik Surtani Node.put(Map map, boolean erase) was removed in 2.0. Users wishing to emulate the replace-all behavior (e.g. put(map, true)) in 2.0 must now use a TransactionManager to do first the clear then the putAll(). The docs suggest for stand-alone installs to use the DummyTXMan, but also say it's not production ready. I would suggest renaming DummyTXM to NonDurableTXM and clarifying the documents. It'd be also wise to have a section on migration, e.g. "What happened to XXX?" -- 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

19 years, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-975) Getting message payload returns null after messages is serialized

by Tim Fox (JIRA)

Getting message payload returns null after messages is serialized ----------------------------------------------------------------- Key: JBMESSAGING-975 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-975 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.3.0.GA If retrieve a list of messages using JMX operation listAllMessages, then try to inspect the payload, e.g. TextMessage::getText() then it returns 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

19 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1413) The Portlet Instance list should have a field label describing what it is

by Thomas Heute (JIRA)

The Portlet Instance list should have a field label describing what it is ------------------------------------------------------------------------- Key: JBPORTAL-1413 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1413 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.CR2 Reporter: Thomas Heute Assigned To: Thomas Heute Fix For: 2.6 Final The Portlet Instance list should have a field label describing what it is. Perhaps "Portlet Instance used by this window:". -- 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

19 years, 2 months

1
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1073) nodePassivated/nodeActivated callbacks in CacheListener to provide data

by Manik Surtani (JIRA)

nodePassivated/nodeActivated callbacks in CacheListener to provide data ----------------------------------------------------------------------- Key: JBCACHE-1073 URL: http://jira.jboss.com/jira/browse/JBCACHE-1073 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.CR2, 2.0.0.GA >From an email thread with Brian: The EJB3 SFSB layer needs access to the data in the relevant node when it gets a nodePassivated(fqn, true) callback. It needs it so it can get the bean context and invoke any @PrePassivate methods. When it gets the data, it can't go through the interceptor chain or that causes a bunch of problems that we sorted last fall and early this year. In CR2 getting this data w/o going through the interceptors is now impossible, at least w/o some nasty hacks I haven't dreamed up yet. In 1.4 we did it with the now removed peek() method. Earlier in 2.0 we used Option.setBypassInterceptorChain(), but it seems that is now gone as well. How about we change the method signature of the notification to provide the data in the callback? Looking at the PassivationInterceptor, this is easy to do -- the data map is sitting right there. If we do, this data param should be null in the 'post' callback. -- 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

19 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1075) JGroups file in lib should be named jgroups-all.jar

by Brian Stansberry (JIRA)

JGroups file in lib should be named jgroups-all.jar --------------------------------------------------- Key: JBCACHE-1075 URL: http://jira.jboss.com/jira/browse/JBCACHE-1075 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.0.0.CR2 Name the file jgroups-all.jar, which is what it's named in the JGroups dist. Using a different name makes it too easy to end up with duplicate jars when upgrading, a mistake I've made several times and which we hear about on support from time to time. This is more an AS issue (JBAS-4446) but we might as well do the same thing in JBC. -- 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

19 years, 2 months

2
3
0 / 0

[JBoss JIRA] Commented: (JBAS-3215) Add 'grace period' to deployment scanner between finding a new/changed deployment and actually deploying it

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3215?page=comments#action_12363510 ] Dimitris Andreadis commented on JBAS-3215: ------------------------------------------ There is always the workaround of copying/building the deployment in a different location but on the same filesystem with the ./deploy dir, then moving the whole thing into deploy, which is an atomic operation in most filesystems. > Add 'grace period' to deployment scanner between finding a new/changed deployment and actually deploying it > ----------------------------------------------------------------------------------------------------------- > > Key: JBAS-3215 > URL: http://jira.jboss.com/jira/browse/JBAS-3215 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: System service > Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.CR2 > Environment: jboss-4.0.3SP1 and jboss-4.0.4CR2 on Windows 2000 server using JVM 1.5.04 > WAR file is built on JDK 1.5.04 using the ANT 1.6.5 WAR task > Reporter: David Richmond > Assigned To: Dimitris Andreadis > > To avoid unpredictable "org.jboss.deployment.DeploymentException: Unexpected end of ZLIB input stream" exceptions could a grace period (delay) be added to the JBoss deployment deployer. This delay should be applied as follows: > 1. Scanner finds new deployments > 2. WAIT for grace period > 3. Scanner deploys new deployments > Setting the grace-period to 0 would emulate the current JBoss behaviour -- 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

19 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-497) Message bundling seems to add latency well beyond max_bundle_timeout

by Brian Stansberry (JIRA)

Message bundling seems to add latency well beyond max_bundle_timeout -------------------------------------------------------------------- Key: JGRP-497 URL: http://jira.jboss.com/jira/browse/JGRP-497 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP3 Reporter: Brian Stansberry Assigned To: Bela Ban Short synopsis: with bundling enabled and max_bundle_timeout=30 ms, I'm sometimes seeing 700 ms delay in receiver getting a message, leading to transient AS testsuite failures. Disabling bundling makes the transient failures go away. Long discussion: The JBoss AS testsuite has been seeing intermittent failures of the asynchronous web session replication tests. Particularly with FIELD granularity tests. Basically, test modifies a session on one node, waits 500 ms, then fails over to the other node, expecting consistent state. Test fails if the session state is not as expected. Whenever I investigate the intermittent failure, it's always a case of the asynchronous replication message arriving after the failover request. TRACE logging of JBoss Cache shows sometimes a 700 ms delay between the sender cache sending the replication and the receiver receiving it. That's just too long! Causes I could think of: 1) Some up_thread/down_thread set to true, leaving a message sitting in a queue for a while until the OS schedules the thread. We used to see this problem. Nope -- all threads are set to false. 2) Bad luck; full gc happens at the wrong time. Possible but IMO unlikely; the failures occur too often and its not like these tests are generating a ton of garbage that's forcing a lot of full gc runs. 3) System is under some other load during the relevant period. Unlikely. The client is sleeping and the servers have nothing else going on. 4) Message bundling. It's turned on, but max_bundle_timeout is 30 ms, so the latency it adds to an async RPC should be minimal. But, I just disabled bundling and have now run the async FIELD tests about 10 times with no failures. With it enabled I'd get a failure in some test on average nearly once per run. Perhaps there is something that's preventing the Bundler task executing on the expected schedule? -- 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

19 years, 2 months

2
8
0 / 0

[JBoss JIRA] Commented: (JBAS-3215) Add 'grace period' to deployment scanner between finding a new/changed deployment and actually deploying it

by David Richmond (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3215?page=comments#action_12363503 ] David Richmond commented on JBAS-3215: -------------------------------------- I would off thought this problem, although mundane, would be fairly high on the to do list. I mean, EJB, Seam, JBossTS etc are all worthless if you cannot deploy your application reliably. I would love to help, but my team leader has just left the company, I have 6 projects on the go, and upgrading from JBoss 4.0.5 to 4.2.0 is proving to be a real pain in the *&*% - and that just the stuff going on at work ;-) Dave http://www.jboss.com/index.html?module=bb&op=viewtopic&t=108746 http://www.jboss.com/index.html?module=bb&op=viewtopic&t=109361 > Add 'grace period' to deployment scanner between finding a new/changed deployment and actually deploying it > ----------------------------------------------------------------------------------------------------------- > > Key: JBAS-3215 > URL: http://jira.jboss.com/jira/browse/JBAS-3215 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: System service > Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.CR2 > Environment: jboss-4.0.3SP1 and jboss-4.0.4CR2 on Windows 2000 server using JVM 1.5.04 > WAR file is built on JDK 1.5.04 using the ANT 1.6.5 WAR task > Reporter: David Richmond > Assigned To: Dimitris Andreadis > > To avoid unpredictable "org.jboss.deployment.DeploymentException: Unexpected end of ZLIB input stream" exceptions could a grace period (delay) be added to the JBoss deployment deployer. This delay should be applied as follows: > 1. Scanner finds new deployments > 2. WAIT for grace period > 3. Scanner deploys new deployments > Setting the grace-period to 0 would emulate the current JBoss behaviour -- 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

19 years, 2 months

1
0
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 May 2007