February 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8414) Enable schema validation in development

by Thomas Diesler (JIRA)

Enable schema validation in development --------------------------------------- Key: JBAS-8414 URL: https://jira.jboss.org/browse/JBAS-8414 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: XML services Reporter: Thomas Diesler Assignee: Alexey Loubyansky Fix For: 7.0.0.M1 The server configuration that we ship (i.e. standalone.xml) should be in sync with the schemas that it references If there is no automated schema validation chances are high that the xml configuration is not in sync with the respective subsystem schemas, which should be the input for tooling I suppose. -- 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, 7 months

7
14
0 / 0

[JBoss JIRA] Created: (JBAS-8316) Simple command line installer

by Brian Stansberry (JIRA)

Simple command line installer ----------------------------- Key: JBAS-8316 URL: https://jira.jboss.org/browse/JBAS-8316 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: 7.0.0.M1 The AS is going to support two different running modes (see "Standalone Server" vs the rest of the discussion on http://community.jboss.org/docs/DOC-15215) and a flexible configuration for defining the "profile" a server will run. Profiles will not be represented via filesystem directories; rather they will be pure configuration. The two different running modes will result in slightly different filesystem layouts -- see discussion in http://community.jboss.org/thread/153858. The upshot of all this is using AS 7 will not be like previous versions where you could download the distribution, unzip, cd to bin/ and type ./run.sh -c some-std-config". Rather, I envision something like this: 1) download, unzip, cd bin 2) ./install.sh --someparamstotellitwhatyouwant Params to tell it what you want would be whether you're running in standalone mode or full domain, which of a set of pre-packaged profiles you want, maybe some more stuff. From this, installer would create the appropriate filesystem layout, generate a domain.xml+host.mxl or standalone.xml 3) ./run.sh -- 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, 7 months

3
9
0 / 0

[JBoss JIRA] Created: (JBAS-8791) log4j-appender seems not working in jboss-logging (AS6 final)

by Gregoire Botquin (JIRA)

log4j-appender seems not working in jboss-logging (AS6 final) ------------------------------------------------------------- Key: JBAS-8791 URL: https://issues.jboss.org/browse/JBAS-8791 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: 6.0.0.Final Reporter: Gregoire Botquin Assignee: David Lloyd We are using some custom logger based on log4j appenders. I made a jboss-logging.xml configuration but it seems that my log4j-appender doesn't log anything. I'm working in AS6 final version. I made an example with a standard log4j appender (neither working). The category "com.sample" should be managed by the log4jappender. Every second the bean should write something, but nothing happens, the log file is not even created. I tried with other log4j loggers/ custom loggers and no success. When activating CONSOLE handler the logs are correctly written in console, but when only using the log4j-appender nothing happens after server started. The configuration file seems correct (?), but can't unfortunately check it against a documentation yet. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- <logging xmlns="urn:jboss:logging:6.0" xmlns:b="urn:jboss:bean-deployer:2.0">     <periodic-rotating-file-handler file-name="${jboss.server.log.dir}/server.log" name="FILE" autoflush="true" append="true" suffix=".yyyy-MM-dd">  <error-manager> <only-once/> </error-manager> <formatter>    <pattern-formatter pattern="%d %-5p [%c] (%t) %s%E%n"/> </formatter> </periodic-rotating-file-handler>    <console-handler name="CONSOLE" autoflush="true" target="System.out"> <error-manager> <only-once/> </error-manager> <level name="INFO"/> <formatter> <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] %s%E%n"/> </formatter> </console-handler> <log4j-appender name="Log4jAppender" class="org.apache.log4j.DailyRollingFileAppender"> <error-manager> <only-once/> </error-manager> <level name="DEBUG"/> <properties>  <property name="file">${jboss.server.log.dir}/log4j.log</property> <property name="append">true</property> <property name="datePattern">'.'yyyy-MM-dd</property> </properties> <formatter> <pattern-formatter pattern="%d %-5p [%c] %m%n"/> </formatter> </log4j-appender> <logger category="com.sample"> <level name="DEBUG"/> <handlers> <handler-ref name="Log4jAppender"/> </handlers> </logger>    <root-logger>  <level name="${jboss.server.log.threshold:INFO}"/> <handlers> <handler-ref name="Log4jAppender"/>  </handlers> </root-logger> </logging> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- package com.sample; import javax.ejb.Schedule; import javax.ejb.Stateless; import org.apache.log4j.Logger; //@Singleton @Stateless public class TestBean { public static final Logger LOG = Logger.getLogger(TestBean.class); public TestBean(){ System.out.println("TestBean is instantiated and should write someting in the log file"); LOG.info("This is information log"); } @Schedule(second="*/1", minute="*",hour="*", persistent=false) public void writeSomething(){ System.out.println("This should write something in the log file at scheduled times"); LOG.info("This is scheduled information log"); } } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

9
17
0 / 0

[JBoss JIRA] Created: (JBAS-7468) Memory leak in org.jboss.security.plugins.authorization.JBossAuthorizationContext

by Ganesh Ingle (JIRA)

Memory leak in org.jboss.security.plugins.authorization.JBossAuthorizationContext --------------------------------------------------------------------------------- Key: JBAS-7468 URL: https://jira.jboss.org/jira/browse/JBAS-7468 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA, JBossAS-5.0.0.GA Environment: JBoss Version: jboss-5.1.0.GA, OS: Linux (2.6.18-164.el5), Architecture: amd64 64bit, JVM: Java HotSpot(TM) 64-Bit Server VM (14.0-b16, mixed mode) Reporter: Ganesh Ingle Assignee: Anil Saldhana Our use case (only security related portion is mentioned here): Axis 1.4 webservice, standard J2EE declarative security through WEB-INF/web.xml, a http client sends soap request and BASIC auth information, the JBoss server performs authentication and authorization as per WEB-INF/web.xml configuration. We did a performance/stability test on above web service. After 8.5 million requests the server gone out of memory. We did heap dump analysis using VisualVM tool and found that the class org.jboss.security.plugins.authorization.JBossAuthorizationContext is consuming most of the memory. This class has a memer array named "controlFlags", this array was showing 25.7 million ControlFlag entries. When we investigated the code we found that there is one instance of JBossAuthorizationManager per security domain and this manager has one instance of JBossAuthorizationContext. For every authorization the JBossAuthorizationContext initializes authorization modules and pushes their control flags (instances of class ControlFlag) in member arrays. When the authorization is complete, a commit/abort is invoked on all modules and finally the "modules" array is cleared. However, the "controlFlags" array is not cleared. We checked the entire class, this array never gets cleared. We changed the code to clear both "modules" and "controlFlags" array in a finally block in method JBossAuthorizationContext.authorize(final Resource resource, final Subject subject, final RoleGroup callerRoles). We ran a 50million test after this fix, the test was successful which proves the fix worked. -- 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, 7 months

7
13
0 / 0

[JBoss JIRA] Created: (JGRP-872) TP: cluster name is shipped with each message

by Bela Ban (JIRA)

TP: cluster name is shipped with each message --------------------------------------------- Key: JGRP-872 URL: https://jira.jboss.org/jira/browse/JGRP-872 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 If a cluster name (the name used in Channel.conect()) is long, because we ship it with each message (in the TP header), this blows up the size of the marshalled messages. Maybe we can canonicalize the cluster name shipped with each message, similar to what we want to do with Addresses, e.g. replace the cluster name with a short. -- 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, 8 months

4
15
0 / 0

[JBoss JIRA] Created: (JGRP-931) Logical addresses: canonicalize UUIDs with IDs (shorts)

by Bela Ban (JIRA)

Logical addresses: canonicalize UUIDs with IDs (shorts) ------------------------------------------------------- Key: JGRP-931 URL: https://jira.jboss.org/jira/browse/JGRP-931 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 Instead of using UUIDs as addresses, the cluster members should agree on shorts, e.g. 1 for A, 2 for B and so on, and use these instead of UUIDs. This happens after a certain warmup time. E.g. the coord could assign these IDs, so they're unique. IdAddress and UUID have to be able to do equals() or compareTo() with each other ! Advantage: - we send a short (2 bytes) instead of a UUID (16 bytes) - we use an IdAddress (class with a short) instead of a UUID. This is 6 bytes less per instance - IdAddress might be faster with equals() and hashCode() than UUID -- 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, 8 months

2
12
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1975) Initial OSGi JPA implementation

by Thomas Diesler (JIRA)

Initial OSGi JPA implementation ------------------------------- Key: EJBTHREE-1975 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1975 Project: EJB 3.0 Issue Type: Feature Request Reporter: Thomas Diesler Part of Enterprise OSGi there is JPA specification that we would like to have support for. This issue is the entry point for the initial implementation. Apache Aries ------------------ http://wiki.apache.org/incubator/AriesProposal Apache OpenJPA - http://openjpa.apache.org/ Apache OpenJPA is a Java persistence project. It is related to Aries as a JPA persistence provider, including entity scanning and enhancement. The Aries project will make it easy for JPA persistence providers such as OpenJPA to be used in an OSGi environment and will provide container managed persistence for the Blueprint container. Eclipse Gemini -------------------- http://eclipse.org/proposals/gemini/ The subprojects will be created with the following initial IP components and donating companies: * Blueprint Service Implementation — SpringSource * Web Container Integration code — SpringSource * JPA Integration code for EclipseLink — Oracle * Implementation of JMX Mbeans and composite data types — Oracle * Derby JDBC Service Implementation — Oracle * JNDI Service Integration code — Oracle http://www.eclipse.org/eclipselink/ -- 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, 8 months

3
14
0 / 0

[JBoss JIRA] Created: (JBBUILD-523) Issues with custom packaging in maven

by Paul Gier (JIRA)

Issues with custom packaging in maven ------------------------------------- Key: JBBUILD-523 URL: https://jira.jboss.org/jira/browse/JBBUILD-523 Project: JBoss Build System Issue Type: Task Components: Maven Reporter: Paul Gier Fix For: Maven Build - Maint 2009 Steve ran into some issues when using custom packaging for the jdocbook plugin. - Transitive dependency resolution does not work - Two dependencies with the same packaging but different artifact handlers cannot both be resolved, because no info about the handler is encoded into the repo - The plugin containing the custom packaging needs to programmatically register the artifact handler in addition to specifiying it in the components.xml this has to be done by: (1) retrieve the handler using @parameter expression="${component.org.apache.maven.artifact.handler.ArtifactHandler#jdocbook-style}" (2) manually register it using project.getArtifact().setArtifactHandler( artifactHandler ); -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1053) UNICAST: set retransmission timeout based on actual retransmission times

by Bela Ban (JIRA)

UNICAST: set retransmission timeout based on actual retransmission times ------------------------------------------------------------------------ Key: JGRP-1053 URL: https://jira.jboss.org/jira/browse/JGRP-1053 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 UNICAST needs to compute a rolling average of retransmission times, per sender (AckSenderWindow). The retransmission timeout per sender can then be set based on the actual average retransmission times. The advantage is that we throttle retransmission when we have a lot of message loss, and speed it up again when there are no message drops. The function to set the timeout should always compute the new timeot value based on (1) the old value times a decay factor and (2) a new value. The average should go up relatively quickly if the actual retransmission values go up, but come down slowly when the actual values go down. A potential function is shown below: static final double SLOW_DECAY_FACTOR=0.9, FAST_DECAY_FACTOR=0.7; static final double FAST_UP= 1 / FAST_DECAY_FACTOR, SLOW_UP= 1 / SLOW_DECAY_FACTOR; static final double SAFETY_BUFFER=0.3; static double avg=200; public static void main(String[] args) { final long[] times={200,200,400,400,500,500,500,500,500,100,100,100,100,100,100,100,100,100,100,100,100,100}; // final long[] times={200,200,200,200,200,200,200,200,200,200,200}; for(Long val: times) { double result=avg(val); System.out.println(val + ": " + result); } } private static double avg(long val) { double decay, up; if(val > avg) { decay=FAST_DECAY_FACTOR; up=FAST_UP; } else { decay=SLOW_DECAY_FACTOR; up=SLOW_UP; } double old_val=avg * decay; double result=(old_val + val * up) / 2; avg=result; return result * (1 + SAFETY_BUFFER); } -- 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, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-1054) NAKACK: retransmission timeouts based on actual retransmission values

by Bela Ban (JIRA)

NAKACK: retransmission timeouts based on actual retransmission values --------------------------------------------------------------------- Key: JGRP-1054 URL: https://jira.jboss.org/jira/browse/JGRP-1054 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 Currently, timeouts in NAKACK are static, e.g. 300,600,1200. The goal is to make the retransmission timeouts a function of the actual average retransmission times. Ideally, we maintain rolling averages of actual retransmission times per sender and adjust the retransmit timeout based on these values. This would dynamically slow down retransmission on heavy traffic/congetion/message loss etc, and speed it up when those problems disappear again -- 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, 8 months

2
6
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 February 2011