September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBJCA-394) Generate report from performance data

by Jeff Zhang (JIRA)

Generate report from performance data ------------------------------------- Key: JBJCA-394 URL: https://jira.jboss.org/browse/JBJCA-394 Project: IronJacamar Issue Type: Task Components: Performance Reporter: Jeff Zhang Assignee: Jeff Zhang Fix For: 1.0.0.Beta2 -- 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

15 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBJCA-298) Maven plugin for validate tool

by Jeff Zhang (JIRA)

Maven plugin for validate tool ------------------------------ Key: JBJCA-298 URL: https://jira.jboss.org/jira/browse/JBJCA-298 Project: JBoss JCA Issue Type: Task Components: Validator Reporter: Jeff Zhang Assignee: Jeff Zhang make a maven plugin for validate tool that user can use it in the maven pom.xml -- 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

15 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-8395) SessionContextListeners are not instantiated/invoked for CDI deployments

by Marius Bogoevici (JIRA)

SessionContextListeners are not instantiated/invoked for CDI deployments ------------------------------------------------------------------------ Key: JBAS-8395 URL: https://jira.jboss.org/browse/JBAS-8395 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Weld/CDI Reporter: Marius Bogoevici Assignee: Marius Bogoevici Priority: Blocker Fix For: 6.0.0.CR1 Needs investigation. SessionContextListeners registered in web.xml are not instantiated and invoked. This causes a number of tests (including TCK tests) to fail. However, CDI-specific Listeners which are installed via JBossWebMetaData are instantiated and invoked 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

15 years, 8 months

1
2
0 / 0

[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

15 years, 8 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

15 years, 8 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

15 years, 8 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

15 years, 8 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

15 years, 8 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

15 years, 8 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

15 years, 8 months

2
2
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 September 2010