September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCOMMON-98) Release jboss-common 1.2.2.GA

by Dimitris Andreadis (JIRA)

Release jboss-common 1.2.2.GA ----------------------------- Key: JBCOMMON-98 URL: https://jira.jboss.org/jira/browse/JBCOMMON-98 Project: JBoss Common Issue Type: Release Security Level: Public (Everyone can see) Components: common-old (1.x) Reporter: Dimitris Andreadis Assignee: Dimitris Andreadis Fix For: 1.2.2.GA -- 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

13 years, 12 months

1
5
0 / 0

[JBoss JIRA] Created: (JGRP-1229) Deadlock during flush

by Markus Hampel (JIRA)

Deadlock during flush --------------------- Key: JGRP-1229 URL: https://jira.jboss.org/browse/JGRP-1229 Project: JGroups Issue Type: Bug Affects Versions: 2.10 Environment: Windows Vista, JDK 1.6.0_10, JGroups 2.10.0, JGroups config: flush-tcp.xml with TCPGOSSIP Reporter: Markus Hampel Assignee: Bela Ban In my environment a deadlock during flush occurs under following circumstances: A message is processed wich sends another multicast message. During the processing of the message GMS starts a flush. The sending of the multicast message blocks and the flush fails because the processed message doesn't end. The ABORT_FLUSH message isn't processed because it's not a OOB message. The blocked message never unblocks. The following Threaddump shows the GMS thread and the message processing thread: "ViewHandler,Test,#A" prio=6 tid=0x04015c00 nid=0x1e8 waiting on condition [0x04b0f000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at org.jgroups.util.Util.sleep(Util.java:1298) at org.jgroups.util.Util.sleepRandom(Util.java:1377) at org.jgroups.protocols.pbcast.GMS._startFlush(GMS.java:721) at org.jgroups.protocols.pbcast.GMS.startFlush(GMS.java:694) at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:189) at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1390) at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1344) at java.lang.Thread.run(Thread.java:619) "Incoming-4,Test,#A" prio=6 tid=0x04014000 nid=0x11f4 waiting on condition [0x0497e000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x248b2cd8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2054) at org.jgroups.protocols.pbcast.FLUSH.blockMessageDuringFlush(FLUSH.java:321) at org.jgroups.protocols.pbcast.FLUSH.down(FLUSH.java:254) at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:894) at org.jgroups.JChannel.down(JChannel.java:1623) at org.jgroups.JChannel.send(JChannel.java:724) ... (Usercode) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:640) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:772) at org.jgroups.JChannel.up(JChannel.java:1453) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:887) at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:435) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:151) at org.jgroups.protocols.FRAG2.up(FRAG2.java:188) at org.jgroups.protocols.FC.up(FC.java:474) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:888) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:614) at org.jgroups.protocols.UNICAST.up(UNICAST.java:294) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:707) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:132) at org.jgroups.protocols.FD.up(FD.java:266) at org.jgroups.protocols.MERGE2.up(MERGE2.java:210) at org.jgroups.protocols.Discovery.up(Discovery.java:281) at org.jgroups.protocols.TP.passMessageUp(TP.java:1009) at org.jgroups.protocols.TP.access$100(TP.java:56) at org.jgroups.protocols.TP$3.run(TP.java:933) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) DEBUG output: 19.08.2010 13:47:41 org.jgroups.logging.JDKLogImpl debug FEIN: new=[#C], suspected=[], leaving=[], new view: [#A|1] [#A, #C] 19.08.2010 13:47:41 org.jgroups.logging.JDKLogImpl debug FEIN: #A: flush coordinator is starting FLUSH with participants [#A] 19.08.2010 13:47:41 org.jgroups.logging.JDKLogImpl debug FEIN: #A: received START_FLUSH, responded with FLUSH_COMPLETED to #A 19.08.2010 13:47:41 org.jgroups.logging.JDKLogImpl debug FEIN: #A: blocking for 10000ms 19.08.2010 13:47:43 org.jgroups.logging.JDKLogImpl debug FEIN: #A: timed out waiting for flush responses after 2000 ms. Rejecting flush to participants [#A] 19.08.2010 13:47:51 org.jgroups.logging.JDKLogImpl debug FEIN: #A: blocking for 10000ms 19.08.2010 13:47:55 org.jgroups.logging.JDKLogImpl warn WARNUNG: #A: GMS flush by coordinator failed 19.08.2010 13:47:55 org.jgroups.logging.JDKLogImpl debug FEIN: resuming message garbage collection 19.08.2010 13:47:55 org.jgroups.logging.JDKLogImpl debug FEIN: new=[#B], suspected=[], leaving=[], new view: [#A|2] [#A, #C, #B] 19.08.2010 13:48:01 org.jgroups.logging.JDKLogImpl debug FEIN: #A: blocking for 10000ms 19.08.2010 13:48:06 org.jgroups.logging.JDKLogImpl warn WARNUNG: #A: GMS flush by coordinator failed ... My solution (that works in my environment, but I can't overlook if it's correct): Changes to org.jgroups.protocols.pbcast.FLUSH // 1. set the OOB flag for the ABORT_FLUSH message 552 private void rejectFlush(Collection<? extends Address> participants, long viewId) { 553 for (Address flushMember : participants) { 554 Message reject = new Message(flushMember, localAddress, null); 555! reject.setFlag(Message.OOB); // 2. the processing of the ABORT_FLUSH message has at least to set "isBlockingFlushDown = false" // but I copied the complete implementation from the "onStopFlush" method 336 public Object up(Event evt) { ... 368 case FlushHeader.ABORT_FLUSH: ... 379! synchronized (sharedLock) { 380! flushCompletedMap.clear(); 381! flushNotCompletedMap.clear(); 382! flushMembers.clear(); 383! suspected.clear(); 384! flushCoordinator = null; 385! flushCompleted = false; 386! } 387! blockMutex.lock(); 388! try { 389! isBlockingFlushDown = false; 390! notBlockedDown.signalAll(); 391! } finally { 392! blockMutex.unlock(); 393! } 394! flushInProgress.set(false); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

3
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2086) Missing interpretation of EJB-Annotation results in wrong call of dynamic method

by Tobias Grundmann (JIRA)

Missing interpretation of EJB-Annotation results in wrong call of dynamic method --------------------------------------------------------------------------------- Key: EJBTHREE-2086 URL: https://jira.jboss.org/jira/browse/EJBTHREE-2086 Project: EJB 3.0 Issue Type: Bug Components: ejb3 Affects Versions: trunk Environment: java version "1.6.0_18" Reporter: Tobias Grundmann when looking up a method for invocation in StatefulContainer.dynamicInvoke():522 jboss tries to determine if it's an EJB-Object-Method via SessionSpecContainer.isEjBObjectMethod(). This results wrongly in "false" if the class in question doesn't implement EJBObject but has e.g. a @Stateful annotation. Futher the method EJBContainer.getNonBridgeMethod() seems to be rather optimistic in trying to find the correct method only according to the number of parameters. This was tested with jboss-6.0.0.M1, but the corresponding code in trunk seems to be the same. -- 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

13 years, 12 months

3
2
0 / 0

[JBoss JIRA] Created: (JBCOMMON-108) CVE-2009-2693

by Mike Millson (JIRA)

CVE-2009-2693 ------------- Key: JBCOMMON-108 URL: https://jira.jboss.org/jira/browse/JBCOMMON-108 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Components: common-old (1.x) Affects Versions: 1.2.1.GA, 1.0.0.GA Reporter: Mike Millson CVE-2009-2693: When deploying WAR files, the WAR files were not checked for directory traversal attempts. This allows an attacker to create arbitrary content outside of the web root by including entries such as ../../bin/catalina.sh in the WAR. -- 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

13 years, 12 months

2
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-983) @EJB injection fails, RuntimeException, IllegalArgumentException

by dpocock (JIRA)

@EJB injection fails, RuntimeException, IllegalArgumentException ---------------------------------------------------------------- Key: EJBTHREE-983 URL: http://jira.jboss.com/jira/browse/EJBTHREE-983 Project: EJB 3.0 Issue Type: Bug Components: EJB3 Extensions Affects Versions: AS 4.2.0 GA, EJB 3.0 RC9 - Patch 1 Environment: Debian Linux, Sun Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Reporter: dpocock Similar to bug EJBTHREE-862. However, setting `Isolated' to false in $JBOSS_HOME/server/XXX/deploy/ear-deployer.xml does not resolve the issue for me. Here is the scenario: There are two applications, app1.ear and app2.ear. app1.ear contains a stateless session bean, App1Bean, with local and remote interface app2.ear contains a stateless session bean, App2Bean, which has a field defined like so: @EJB(mappedName="app1/App1Bean/local") // I've tried local and remote com.app1.ejb.session.App1 app1; app1.ear and app2.ear are loaded successfully by the application server. When App2Bean is activated, JBoss tries to perform the injections. At this point, the RuntimeException (see stack below) occurs. App2Bean can successfully obtain a reference to app1 bean using the traditional JNDI lookup methods. This is a workaround. When inspecting the stack, notice the presence of IllegalArgumentException, even though the interface matches. 16:22:12,155 ERROR [STDERR] java.lang.RuntimeException: Non matching type for inject of field: App1Bean app1 for type: $Proxy79 of jndiName env/App2Bean/app2 intfs: , App1, org.jboss.ejb3.JBossProxy, javax.ejb.EJBObject 16:22:12,155 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:135) 16:22:12,155 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:104) 16:22:12,155 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:61) 16:22:12,155 ERROR [STDERR] at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:92) 16:22:12,155 ERROR [STDERR] at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48) 16:22:12,165 ERROR [STDERR] at org.jboss.ejb3.cache.simple.SimpleStatefulCache.create(SimpleStatefulCache.java:209) 16:22:12,165 ERROR [STDERR] at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:303) 16:22:12,165 ERROR [STDERR] at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106) 16:22:12,165 ERROR [STDERR] at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) 16:22:12,175 ERROR [STDERR] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828) 16:22:12,175 ERROR [STDERR] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681) 16:22:12,175 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358) 16:22:12,175 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412) 16:22:12,175 ERROR [STDERR] at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239) 16:22:12,185 ERROR [STDERR] Caused by: java.lang.IllegalArgumentException 16:22:12,185 ERROR [STDERR] at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63) 16:22:12,185 ERROR [STDERR] at java.lang.reflect.Field.set(Field.java:656) 16:22:12,185 ERROR [STDERR] at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:119) 16:22:12,185 ERROR [STDERR] ... 13 more -- 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

13 years, 12 months

5
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2170) no-interface view doesn't pass on the invoked business interface to Endpoint

by jaikiran pai (JIRA)

no-interface view doesn't pass on the invoked business interface to Endpoint ---------------------------------------------------------------------------- Key: EJBTHREE-2170 URL: https://jira.jboss.org/browse/EJBTHREE-2170 Project: EJB 3.0 Issue Type: Bug Components: nointerface Affects Versions: depchain-1.0.0-alpha-4 Reporter: jaikiran pai Assignee: jaikiran pai The NoInterfaceViewInvocationHandler passes null as the invoked business interface to the Endpoint: // finally pass-on the control to the endpoint return endpoint.invoke(this.session, null, method, args); Instead, it should be passing the no-interface view type http://download.oracle.com/javaee/6/api/javax/ejb/SessionContext.html#get... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8448) Update parsing code to generate domain updates instead of models directly

by Jason Greene (JIRA)

Update parsing code to generate domain updates instead of models directly ------------------------------------------------------------------------- Key: JBAS-8448 URL: https://jira.jboss.org/browse/JBAS-8448 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jason Greene -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

2
4
0 / 0

[JBoss JIRA] Created: (JBBUILD-645) Nexus index is out of date for "Public Repository Group"

by John Aylward (JIRA)

Nexus index is out of date for "Public Repository Group" -------------------------------------------------------- Key: JBBUILD-645 URL: https://jira.jboss.org/browse/JBBUILD-645 Project: JBoss Build System Issue Type: Task Components: Artifact Repositories Affects Versions: Repository Support 2010 Reporter: John Aylward Fix For: Repository Support 2010 Nexus index is out of date for "Public Repository Group". This prevents creating an effective proxy of the group. see: https://repository.jboss.org/nexus/content/groups/public/.index/ lots of index files in there that look like they may be diffs or perhaps failed attempts at proper indexes. the latest version of the full index (that remote nexus proxies would use) is: nexus-maven-repository-index.gz Fri Apr 16 13:42:23 EDT 2010 workaround: Create proxies for the individual repositories instead Fix: put index generation on a schedule or find out why the current schedule doesn't seem to update the index correctly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-6627) The JMX console /MBean Inspector page doesn't handle org.w3c.dom.Element correctly

by Howard Gao (JIRA)

The JMX console /MBean Inspector page doesn't handle org.w3c.dom.Element correctly ---------------------------------------------------------------------------------- Key: JBAS-6627 URL: https://jira.jboss.org/jira/browse/JBAS-6627 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX/Web Console Affects Versions: JBossAS-4.2.3.GA Reporter: Howard Gao Assignee: Darran Lofthouse When a mbean is opened in the MBeanInspector page, if the mbean has attributes that are of type org.w3c.dom.Element, the corresponding input field cannot display them correctly if the element's value contains special characters like ' (quote). Special characters in this case should be converted to html code in order to be displayed properly on the web browser. See related jira https://jira.jboss.org/jira/browse/JBMESSAGING-1517. -- 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

13 years, 12 months

3
2
0 / 0

[JBoss JIRA] Created: (JBBUILD-526) Add "all" profile to generate and include javadocs in AS build

by Paul Gier (JIRA)

Add "all" profile to generate and include javadocs in AS build -------------------------------------------------------------- Key: JBBUILD-526 URL: https://jira.jboss.org/jira/browse/JBBUILD-526 Project: JBoss Build System Issue Type: Task Reporter: Paul Gier Assignee: Paul Gier Fix For: Maven Build - App Server (Phase 3) The AS build does not currently have the equivalent of the "all" target in the old ant build. This basically involves setting up a profile to call the javadoc plugin, and then updating build-distr.xml to copy the generated javadocs. -- 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

13 years, 12 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2010