July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (LOGTOOL-22) Add additional support for message validation.

by James Perkins (JIRA)

Add additional support for message validation. ---------------------------------------------- Key: LOGTOOL-22 URL: https://issues.jboss.org/browse/LOGTOOL-22 Project: Log Tool Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: James Perkins Assignee: David Lloyd Fix For: 1.0.0.Beta8 Add validation to see if the method parameters match the parameters required for the message. For example, an integer should be passed to String.format("%d"). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
9
0 / 0

[JBoss JIRA] Created: (JBAS-9362) Long running thread leaks SimpleRole objects

by Tim Terlegard (JIRA)

Long running thread leaks SimpleRole objects -------------------------------------------- Key: JBAS-9362 URL: https://issues.jboss.org/browse/JBAS-9362 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: 6.0.0.Final Environment: Tested on Mac OS X 10.6.7 with Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) 1.6.0_24 Reporter: Tim Terlegard Assignee: Anil Saldhana Attachments: simpleroletest.tar.gz When invoking a long-running EJB method which makes a bunch of calls to some method in another EJB, then JBoss leaks SimpleRole objects. The SimpleRole objects are not removed by a manually triggered garbage collection. The SimpleRole object leakage seems to go away if I remove the security domain in jboss.xml. When running my jboss application during the night JBoss had 4GB of SimpleRole objects. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

6
9
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-670) Migrate existing Nexus Audit information to standard XML format

by Paul Gier (JIRA)

Migrate existing Nexus Audit information to standard XML format --------------------------------------------------------------- Key: JBBUILD-670 URL: https://issues.jboss.org/browse/JBBUILD-670 Project: JBoss Build System Issue Type: Task Reporter: Paul Gier Assignee: John Casey Fix For: Build Support 2011 We currently have audit information (username, timestamp) stored in .json files in the repository. Nexus uses an XML format to store this information, and recent versions of Nexus allow easy way to view this information in the Nexus UI. The existing audit information should be migrated to the standard Nexus XML format. These XML files are located in the directory "sonatype-work/nexus/proxy/attributes". For each file in each Maven repository hosted by Nexus, there is a file with the same name in this attributes directory. For example, "sonatype-work/nexus/proxy/attributes/jboss-releases/org/jboss/javaee/jboss-servlet-api/2.5.0.GA/jboss-servlet-api-2.5.0.GA.jar" is actually an XML file containing the attributes for the named jar file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
9
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: (AS7-1326) Cannot redeploy OSGi bundle that is wired to webapp

by Thomas Diesler (JIRA)

Cannot redeploy OSGi bundle that is wired to webapp --------------------------------------------------- Key: AS7-1326 URL: https://issues.jboss.org/browse/AS7-1326 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.0.0.Final Reporter: Thomas Diesler Assignee: Thomas Diesler {code} 09:12:12,719 ERROR [org.jboss.msc.service] (MSC service thread 1-1) MSC00002: Invocation of listener "org.jboss.as.osgi.deployment.BundleStartTracker$1@2789a406" failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.module.spec.service."deployment.jboss-osgi-example-jbossas-bundle"."0.0.0" is already registered at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154) at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226) at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560) at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201) at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194) at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307) at org.jboss.as.osgi.service.ModuleLoaderIntegration.addModule(ModuleLoaderIntegration.java:122) at org.jboss.osgi.framework.internal.ModuleManagerPlugin.createHostModule(ModuleManagerPlugin.java:340) at org.jboss.osgi.framework.internal.ModuleManagerPlugin.addModule(ModuleManagerPlugin.java:225) at org.jboss.osgi.framework.internal.ResolverPlugin.addModules(ResolverPlugin.java:248) at org.jboss.osgi.framework.internal.ResolverPlugin.applyResolverResults(ResolverPlugin.java:226) at org.jboss.osgi.framework.internal.ResolverPlugin.resolve(ResolverPlugin.java:161) at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:551) at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:210) at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:494) at org.jboss.as.osgi.deployment.BundleStartTracker$1.processService(BundleStartTracker.java:146) at org.jboss.as.osgi.deployment.BundleStartTracker$1.transition(BundleStartTracker.java:121) {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
9
0 / 0

[JBoss JIRA] Created: (AS7-735) Failed OSGi deployments still show as .deployed in hotdeploy folder

by David Bosschaert (JIRA)

Failed OSGi deployments still show as .deployed in hotdeploy folder ------------------------------------------------------------------- Key: AS7-735 URL: https://issues.jboss.org/browse/AS7-735 Project: Application Server 7 Issue Type: Bug Components: OSGi Affects Versions: 7.0.0.CR1 Reporter: David Bosschaert Assignee: Jason Greene When deploying a bundle in AS7 in the hotdeploy directory that has missing dependencies and therefore fails the OSGi resolution process, the deployment still shows up as deployed successfully (a .deployed file appears). I think it should be marked as .failed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
15
0 / 0

[JBoss JIRA] Created: (JGRP-1302) RELAY: issues with shared transport

by Bela Ban (JIRA)

RELAY: issues with shared transport ----------------------------------- Key: JGRP-1302 URL: https://issues.jboss.org/browse/JGRP-1302 Project: JGroups Issue Type: Task Affects Versions: 2.12 Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12.1 JBoss 6 creates a separate channel for each of its webapps that are marked as <distributable/> when mode=distribution. The reason is outlined in https://issues.jboss.org/browse/ISPN-658. This is a problem if we have for example a stack called "relay" (and in infinispan-configs.xml the "web" configuration refers to "relay"), and the transport is shared (singleton_name is set): - webapp web.war is deployed - A channel for web.war is created by Infinispan - The channel creates the shared transport and RELAY establishes the TCP bridge cluster as first member - Webapp SessionDemo.war is deployed - A new channel is created. The shared transport is not initialized again, as it already was for web.war - However, RELAY joins the TCP bridge cluster and thus is in the same cluster as web.war ! ==> However, both subclusters are named the same ! This leads to issues -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
5
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 July 2011