January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1128) Add a full component-info.xml to source tree

by Brian Stansberry (JIRA)

Add a full component-info.xml to source tree -------------------------------------------- Key: JBCACHE-1128 URL: http://jira.jboss.com/jira/browse/JBCACHE-1128 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: 2.0.0.GA The component-info.xml that goes into repository.jboss.org should be coming from the JBC source tree. -- 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
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-759) Create a set of deadlock-detecting unit tests

by Manik Surtani (JIRA)

Create a set of deadlock-detecting unit tests --------------------------------------------- Key: JBCACHE-759 URL: http://jira.jboss.com/jira/browse/JBCACHE-759 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 1.4.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0 >From email thread: "Okay, found out that jconsole also supports it: MBeans --> java.lang --> Threading --> Operations --> findMonitorDeadlockedThreads(). Of course, if we could integrate this into our test suites to regularly check for deadlocks..." Article from JavaSpecialists: http://www.javaspecialists.co.za/archive/newsletter.do?issue=130&locale=e... -- 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: (JBPORTAL-1738) can not access a member of class org.jboss.portal.portlet.impl.jsr168.taglib.GenerateURLTag

by David Schlechtweg (JIRA)

can not access a member of class org.jboss.portal.portlet.impl.jsr168.taglib.GenerateURLTag ------------------------------------------------------------------------------------------- Key: JBPORTAL-1738 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1738 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Portlet Affects Versions: 2.6.2 Final Reporter: David Schlechtweg Assigned To: Julien Viet Hi, i get a IllegalAccessException when i use a jsp tag in freemarker: <#assign portlet=JspTaglibs["http://java.sun.com/portlet"]> <#import "/spring.ftl" as spring /> <@portlet.actionURL var="postURL"> <@portlet.param name="action" value="newQuery" /> </(a)portlet.actionURL> I use freemarker 2.3.10 in jboss-portal-2.6.2.GA java.lang.IllegalAccessException: Class freemarker.ext.jsp.TagTransformModel can not access a member of class org.jboss.portal.portlet.impl.jsr168.taglib.GenerateURLTag with modifiers "public" The problematic instruction: ---------- ==> user-directive portlet.actionURL [on line 3, column 1 in template/search/simple/view.ftl] ---------- Java backtrace for programmers: ---------- freemarker.template.TemplateModelException: java.lang.IllegalAccessException: Class freemarker.ext.jsp.TagTransformModel can not access a member of class org.jboss.portal.portlet.impl.jsr168.taglib.GenerateURLTag with modifiers "public" at freemarker.ext.jsp.TagTransformModel.getWriter(TagTransformModel.java:177) at freemarker.core.Environment.visit(Environment.java:220) at freemarker.core.UnifiedCall.accept(UnifiedCall.java:116) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.MixedContent.accept(MixedContent.java:92) at freemarker.core.Environment.visit(Environment.java:196) at freemarker.core.Environment.process(Environment.java:176) at freemarker.template.Template.process(Template.java:232) at org.springframework.web.servlet.view.freemarker.FreeMarkerView.processTemplate(FreeMarkerView.java:344) any ideas? My hunch is that the class org.jboss.portal.portlet.impl.jsr168.taglib.GenerateURLTag is not public, and you're trying to invoke a method on it that though itself is public, it is not declared in any public superclass of GenerateURLTag, or public interface that GenerateURLTag implements. -- 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
2
0 / 0

[JBoss JIRA] Created: (JGRP-666) The thread is blocked when join the group.

by Liu Torr (JIRA)

The thread is blocked when join the group. ------------------------------------------ Key: JGRP-666 URL: http://jira.jboss.com/jira/browse/JGRP-666 Project: JGroups Issue Type: Bug Affects Versions: 2.6.1 Environment: Windox XP Sun JDK 1.5 ; Jgroup 2.6.1 Reporter: Liu Torr Assigned To: Bela Ban Priority: Critical Run this test case in three window that we can all them as A, B, C. after starting all these tree, then stop C first and resart it quickly, then B, and A. public class TestJoin { public static final String DEFAULT_PROTOCOL_STACK= "UDP(mcast_addr=228.8.8.8;mcast_port=45566;ip_ttl=32;mcast_send_buf_size=150000;" + "mcast_recv_buf_size=80000):" + "PING(timeout=2000;num_initial_members=2):MERGE2(min_interval=5000;max_interval=10000):" + "FD_SOCK:" + "FD(timeout=10000;max_tries=5;shun=true):" + "VERIFY_SUSPECT(timeout=12500):" + "pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800;max_xmit_size=8192):" + "UNICAST(timeout=300,600,1200,2400):pbcast.STABLE(desired_avg_gossip=20000):" + "FRAG(frag_size=8096;down_thread=false;up_thread=false):" + "pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=false)"; public static void main(String[] args) { NotificationBus bus; try { bus = new NotificationBus ( "test", DEFAULT_PROTOCOL_STACK ); bus.getChannel ().setOpt ( Channel.LOCAL, Boolean.FALSE ); bus.start (); } catch (Exception e) { // TODO Auto-generated catch block e.printStackTrace(); } while(true) { System.out.println("******************************************"); try { Thread.sleep(5000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } } And after that, the A and B will be blocked for joining the group. here is hte console output: (it should join the group and output the ****************) 2008-1-18 10:49:15 org.jgroups.JChannel init Info: JGroups version: 2.6.1 2008-1-18 10:49:16 org.jgroups.protocols.pbcast.NAKACK setProperties Warn: max_xmit_size was deprecated in 2.6 and will be ignored 2008-1-18 10:49:16 org.jgroups.stack.Protocol setPropertiesInternal Warn: down_thread was deprecated and is ignored 2008-1-18 10:49:16 org.jgroups.stack.Protocol setPropertiesInternal Warn: up_thread was deprecated and is ignored 2008-1-18 10:49:16 org.jgroups.protocols.pbcast.GMS setProperties Warn: join_retry_timeout has been deprecated and its value will be ignored 2008-1-18 10:49:21 org.jgroups.protocols.pbcast.ClientGmsImpl join Warn: join(10.70.148.165:1371) sent to 10.70.148.165:1350 timed out (after 5000 ms), retrying 2008-1-18 10:49:26 org.jgroups.protocols.pbcast.ClientGmsImpl join Warn: join(10.70.148.165:1371) sent to 10.70.148.165:1350 timed out (after 5000 ms), retrying 2008-1-18 10:49:31 org.jgroups.protocols.pbcast.ClientGmsImpl join Warn: join(10.70.148.165:1371) sent to 10.70.148.165:1350 timed out (after 5000 ms), retrying 2008-1-18 10:49:36 org.jgroups.protocols.pbcast.ClientGmsImpl join Warn: join(10.70.148.165:1371) sent to 10.70.148.165:1350 timed out (after 5000 ms), retrying 2008-1-18 10:49:41 org.jgroups.protocols.pbcast.ClientGmsImpl join Warn: join(10.70.148.165:1371) sent to 10.70.148.165:1350 timed out (after 5000 ms), retrying 2008-1-18 10:49:46 org.jgroups.protocols.pbcast.ClientGmsImpl join Warn: join(10.70.148.165:1371) sent to 10.70.148.165:1350 timed out (after 5000 ms), retrying I have used Jgroups 2.2.9, and the same problem happened (different console output with more message trace information.). -- 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
9
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-152) Dependency names need to be validated earlier

by Scott M Stark (JIRA)

Dependency names need to be validated earlier --------------------------------------------- Key: JBMICROCONT-152 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-152 Project: JBoss MicroContainer Issue Type: Bug Components: Dependency Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC_2_0_0 Beta3 I'm seeing an error like the following testing profileservice attachments overrides: Caused by: java.lang.IllegalArgumentException: Null name at org.jboss.dependency.plugins.AbstractController.getContext(AbstractController.java:129) at org.jboss.kernel.plugins.dependency.AbstractKernelController.getContext(AbstractKernelController.java:101) at org.jboss.dependency.plugins.AbstractDependencyItem.resolve(AbstractDependencyItem.java:117) at org.jboss.dependency.plugins.AbstractDependencyInfo.resolveDependencies(AbstractDependencyInfo.java:128) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:595) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:531) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192) at org.jboss.system.ServiceController.doInstall(ServiceController.java:638) at org.jboss.system.ServiceController.install(ServiceController.java:271) This error regarding the invalid dependency item name not showing up until there is an attempt to resolve it makes it impossible to debug the problem as there is no context in the dependency to understand why its 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, 6 months

3
11
0 / 0

[JBoss JIRA] Created: (JBAS-5189) Txn-Manager arjuna commits data after timeout in long transactions

by Rￃﾼdiger Schmitz (JIRA)

Txn-Manager arjuna commits data after timeout in long transactions ------------------------------------------------------------------ Key: JBAS-5189 URL: http://jira.jboss.com/jira/browse/JBAS-5189 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager Affects Versions: JBossAS-4.2.0.GA Reporter: Rￃﾼdiger Schmitz Assigned To: Adrian Brock We encountered the following situation: Within an ejb using hibernate (and it's JTA transaction manager) we execute a long transaction. When the transaction run-time exceeds the arjuna timeout, the container outputs the following message: > Abort of action id -5ea551d8:b05:47a18b1f:2f invoked while multiple threads active within it > CheckedAction::check - atomic action -5ea551d8:b05:47a18b1f:2f aborting with 1 threads active! After this, all following operations are directly committed to the database! So, basically we have two problems: - The timeout of the txn-manager triggers, even while the current database transaction is in continuous heavy use (numerous inserts/selects per second) - Instead of aborting with an exception at once, the transaction manager happily carries on accepting data - The data sent to the database _before_ the timeout is discard - The data sent to the database _after_ the timeout is committed to the database. This results in inconsistent data within the database - After the ejb-method commits an exception is thrown, leaving the database in an inconsistent state. A workaround is of course to increase the transaction manager timeout, but this defeats the purpose of the timeout. Furthermore, the duration of a transaction cannot always be estimated. -- 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
1
0 / 0

[JBoss JIRA] Created: (JBOSGI-10) OSGi Listeners

by Adrian Brock (JIRA)

OSGi Listeners -------------- Key: JBOSGI-10 URL: http://jira.jboss.com/jira/browse/JBOSGI-10 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Reporter: Adrian Brock Assigned To: Adrian Brock OSGi defines three types of listeners 1) Framework listener for global events related to the server 2) Bundle listener for events related to the deployments 3) Service listener for events related services Where these already exist, these need to be "adapted" to the OSGi api. The missing notifications need to be implemented. -- 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
2
0 / 0

[JBoss JIRA] Created: (JBOSGI-7) OSGi ClassLoader

by Adrian Brock (JIRA)

OSGi ClassLoader ---------------- Key: JBOSGI-7 URL: http://jira.jboss.com/jira/browse/JBOSGI-7 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Reporter: Adrian Brock Assigned To: Adrian Brock Implementation of the OSGi classloader. This should be usable for both OSGi bundles and all other JBoss deployments. An new classloader.xml will be supported such that non OSGi deployments can specify their classloading constraints (import, export, etc.) Additionally, it should provide support for things outside the OSGi spec that are required in JavaEE or for backwards compatibility like scoping and j2se classloading compliance. -- 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: (JBOSGI-4) Deployer changes for OSGi

by Adrian Brock (JIRA)

Deployer changes for OSGi ------------------------- Key: JBOSGI-4 URL: http://jira.jboss.com/jira/browse/JBOSGI-4 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Reporter: Adrian Brock Assigned To: Adrian Brock This is a holder task for the Deployer changes need to make OSGi work and integrate OSGi bundles with other JBoss deployments (and vice versa). -- 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
2
0 / 0

[JBoss JIRA] Created: (JBOSGI-15) Create a concrete subclass of the VFSClassLoaderPolicy that has injectable policy

by Adrian Brock (JIRA)

Create a concrete subclass of the VFSClassLoaderPolicy that has injectable policy --------------------------------------------------------------------------------- Key: JBOSGI-15 URL: http://jira.jboss.com/jira/browse/JBOSGI-15 Project: JBoss OSGi Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Other Reporter: Adrian Brock Assigned To: Adrian Brock Once the VFSClassLoader is done JBOSGI-14, we need to create a concrete subclass that allows injectable policy. i.e. setters. This will be used by the both JBossAS and OSGi through the Deployer layer to construct classloaders from the classloading dependencies/rules they define. -- 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

1
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 January 2008