September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JASSIST-128) GetRefClasses() for anonymous inner classes incorrect

by Jesper Pedersen (JIRA)

GetRefClasses() for anonymous inner classes incorrect ----------------------------------------------------- Key: JASSIST-128 URL: https://jira.jboss.org/browse/JASSIST-128 Project: Javassist Issue Type: Bug Affects Versions: 3.12.0.GA Reporter: Jesper Pedersen Assignee: Shigeru Chiba When getting the referenced classes from an anonymous inner class it incorrectly list a .{Name} reference: CLZ=org.jboss.shrinkwrap.impl.base.container.ContainerBase$1 Collection c = ctClz.getRefClasses(); R=org.jboss.shrinkwrap.impl.base.container.ContainerBase$1 R=org.jboss.shrinkwrap.impl.base.container.ContainerBase R=org.jboss.shrinkwrap.impl.base.container.ContainerBase.1 <-- incorrect -- 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

14 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JASSIST-129) getRefClasses() fails for some of the inner classes defined in java.util

by Maciej Kokocinski (JIRA)

getRefClasses() fails for some of the inner classes defined in java.util ------------------------------------------------------------------------ Key: JASSIST-129 URL: https://jira.jboss.org/browse/JASSIST-129 Project: Javassist Issue Type: Bug Affects Versions: 3.13.0.GA Reporter: Maciej Kokocinski Assignee: Shigeru Chiba CtClass.getRefClasses() reports not existing classes in some cases. One out of many examples is "java.util.LinkedList$DescendingIterator". getRefClasses() for this class returns, as one of the resulting list elements, "istItr" which is obviously wrong as there is no such class. There is a field inside this class named itr of type 'java.util.LinkedList$ListItr". If we get fieldInfo for this field its descriptor is "Ljava/util/LinkedList$ListItr;", however if we take its SignatureAttribute, then its signature is "Ljava/util/LinkedList<TE;>.ListItr;". When this string is parsed during AttributeInfo.renameClass(List, ClassMap) then a class named "istItr" is 'found'. -- 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

14 years, 3 months

2
1
0 / 0

[JBoss JIRA] Updated: (JGRP-100) Large-scale JGroups

by Bela Ban (JIRA)

[ https://jira.jboss.org/browse/JGRP-100?page=com.atlassian.jira.plugin.sys... ] Bela Ban updated JGRP-100: -------------------------- Fix Version/s: 3.0 (was: 2.11) This is work in progress > Large-scale JGroups > ------------------- > > Key: JGRP-100 > URL: https://jira.jboss.org/browse/JGRP-100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.0 > > > - Run JGroups on hundreds of nodes (either physical, or simulation). > - Determine a protocol stack that can be used for large-scale execution > - Example: > - Coordinator may be SPOF. If coord is hung, messages will be sent, but no new views will > be generated > - Retransmission: retransmit from anyone (not sender, otherwise we have NAK implosion) > - Look at PBCAST -- 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

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2168) env-entry with an injection-target but without an explicit env-entry-type fails with java.lang.ClassNotFoundException: Null class name

by jaikiran pai (JIRA)

env-entry with an injection-target but without an explicit env-entry-type fails with java.lang.ClassNotFoundException: Null class name -------------------------------------------------------------------------------------------------------------------------------------- Key: EJBTHREE-2168 URL: https://jira.jboss.org/browse/EJBTHREE-2168 Project: EJB 3.0 Issue Type: Bug Components: core Affects Versions: depchain-1.0.0-alpha-4 Reporter: jaikiran pai Assignee: jaikiran pai Consider the following content in ejb-jar.xml: <session> <ejb-name>Bean</ejb-name> <env-entry> <env-entry-name>someString</env-entry-name> <env-entry-value>Hello world</env-entry-value> <injection-target> <injection-target-class>org.myapp.ejb.MyEJB</injection-target-class> <injection-target-name>someString</injection-target-name> </injection-target> </env-entry> Note that we haven't explicitly specified the env-entry-type element. This runs into: Caused by: java.lang.ClassNotFoundException: Null class name at org.jboss.classloader.plugins.ClassLoaderUtils.checkClassName(ClassLoaderUtils.java:53) [jboss-classloader.jar:2.2.0.Alpha8] at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:425) [jboss-classloader.jar:2.2.0.Alpha8] at java.lang.ClassLoader.loadClass(ClassLoader.java:252) [:1.6.0_16] at org.jboss.injection.EnvEntryEncInjector.getEnvEntryValue(EnvEntryEncInjector.java:66) [:1.5.1] at org.jboss.injection.EnvEntryEncInjector.inject(EnvEntryEncInjector.java:53) [:1.5.1] ... 82 more As per the spec, in the absence of explicit env-entry-type, the type has to be inferred from the injection-target (if present). -- 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

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Resolved: (JBAS-8296) Implement module structure for JBoss AS

by Flavia Rainone (JIRA)

[ https://jira.jboss.org/browse/JBAS-8296?page=com.atlassian.jira.plugin.sy... ] Flavia Rainone resolved JBAS-8296. ---------------------------------- Resolution: Done > Implement module structure for JBoss AS > --------------------------------------- > > Key: JBAS-8296 > URL: https://jira.jboss.org/browse/JBAS-8296 > Project: JBoss Application Server > Issue Type: Feature Request > Components: Weld/CDI > Reporter: Pete Muir > Assignee: Flavia Rainone > Priority: Blocker > Fix For: 6.0.0.CR1 > > > We need to provide the deployment structure to WB using BeanDeploymentArchive structure > http://anonsvn.jboss.org/repos/webbeans/ri/trunk/spi/src/main/java/org/jb... -- 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

14 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBDEPLOY-265) AbstractStructureDeployer.getRelativePath overlooks unrelated paths

by Flavia Rainone (JIRA)

AbstractStructureDeployer.getRelativePath overlooks unrelated paths ------------------------------------------------------------------- Key: JBDEPLOY-265 URL: https://jira.jboss.org/browse/JBDEPLOY-265 Project: JBoss Deployers Issue Type: Bug Components: vfs Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: JBDEPLOY-2.2.0.Beta1 AbstractStructureDeployer must treat the case where child and parent path hold no parent-child relationship. This is needed for correct handling of the classpath entry in the manifest of deployed archives. These entries may refer to jars that are not in the deployed archives; instead, this jars can be anywhere in the file system and may not hold a parent/child relationship with the deployed archive path. -- 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

14 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCOMMON-111) Graph#addEdge() micro optimization

by Ondrej Žižka (JIRA)

Graph#addEdge() micro optimization ---------------------------------- Key: JBCOMMON-111 URL: https://jira.jboss.org/browse/JBCOMMON-111 Project: JBoss Common Issue Type: Quality Risk Security Level: Public (Everyone can see) Affects Versions: 2.2.16.GA Reporter: Ondrej Žižka Assignee: Dimitris Andreadis Priority: Trivial class Graph: public boolean addEdge(Vertex<T> from, Vertex<T> to, int cost) { ... from.addEdge(e); to.addEdge(e); edges.add(e); } class Vertex: public boolean addEdge(Edge<T> e) { if (e.getFrom() == this) outgoingEdges.add(e); else if (e.getTo() == this) incomingEdges.add(e); else return false; return true; } Since the method knows the direction of the edge, why not use this knowledge and avoid unnecessary vertex comparion in Vertex#addEdge() ? public boolean addEdge(Vertex<T> from, Vertex<T> to, int cost) { ... from.addOutgoingEdge(e, cost); to.addIncomingEdge(e, cost); edges.add(e); } addOutgoingEdge and addIncomingEdge do something else -- they create a new edge, which is a bit unintuitive, I'd call them createOutgoingEdge() -- but I hope it's clear what I mean. -- 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

14 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2686) Clean up GWT build for Guvnor

by Geoffrey De Smet (JIRA)

Clean up GWT build for Guvnor ----------------------------- Key: JBRULES-2686 URL: https://jira.jboss.org/browse/JBRULES-2686 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.1.0.FINAL Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: FUTURE * Look into the GWT maven plugin (looks like we don't use it yet?!) * Remove the ANT build files from Guvnor * Remove the generated "cache" files from subversion (if possible) * Get a fast incremental build (from maven + Eclipse + IntelliJ) ** Use GWT shell: changing something and testing it manually should take seconds * Look into automated testings * Look into http://googlewebtoolkit.blogspot.com/2010/08/updated-maven-strategy-for-g... * ... (feel free to suggest) -- 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

14 years, 3 months

2
8
0 / 0

[JBoss JIRA] Created: (JGRP-897) Anycasting: better use of logical addresses

by Bela Ban (JIRA)

Anycasting: better use of logical addresses ------------------------------------------- Key: JGRP-897 URL: https://jira.jboss.org/jira/browse/JGRP-897 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 See whether logical addresses allow us to handle anycasting more efficiently, ie. handle them at the transport level, and not by sending multiple unicasts -- 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

14 years, 3 months

1
9
0 / 0

[JBoss JIRA] Created: (JGRP-1154) FC: separate implementations for multicast and unicast messages

by Bela Ban (JIRA)

FC: separate implementations for multicast and unicast messages --------------------------------------------------------------- Key: JGRP-1154 URL: https://jira.jboss.org/jira/browse/JGRP-1154 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.11 Currently, FC handles both multicast (=group) and unicast messages. This has a few disadvantages: - Complexity - Unicast messages are not dependent on multicast messages (and vice versa), so why should this be different for flow control ? E.g. why should a multicast message block waiting for credits from X because a recent unicast message was sent to X ? - If we have separate flow control protocols for multicasts and unicasts, we can selectively remove one or the other. This is currently not possible Design (see separate documents in ./doc/design): FC_MCAST: ----------------- (see whether some concepts can be borrowed from SFC) Sender: - Every sender has a credits AtomicLong variable - When sending a message and the message length exceeds credits, the sender blocks (until it gets credits from all current group members) - Else credits is decremented by the message length and the message is sent - When credits are received from all current group members, credits is reset to the initial value and all blocked senders are unblocked - When a new member joins, credits is also reset and all blocked senders are unblocked Receiver: - Maintains a hashmap of senders and credits (Map<Address,AtomicLong>) - When a message is received from S, the credits for S are decremented by the message length - If the remaining length is less than the threshold, new credits are sent to S and S's credits are reset to their initial value - When a new member joins, all credits (including the newly joined member) are reset to the initial value FC_UNICAST: -------------------- Sender: - A hashmap of addresses and credits is maintained: every receiver has associated credits - When a message is sent to P, if P's credits minus the message length is less than 0, the sender blocks until it gets new credits from the receiver - Else P's credits are decremented by the message length and the message is sent Receiver: -Same as for FC_MCAST -- 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

14 years, 3 months

1
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2010