January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3816) Wildcard handling in "org.jboss.metadata.MethodAttributes.patternMatches()" isn't correct (or documentation problem)

by Anders Welen (JIRA)

Wildcard handling in "org.jboss.metadata.MethodAttributes.patternMatches()" isn't correct (or documentation problem) -------------------------------------------------------------------------------------------------------------------- Key: JBAS-3816 URL: http://jira.jboss.com/jira/browse/JBAS-3816 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.5.GA Reporter: Anders Welen Priority: Minor Attachments: JBossBug.tgz The method "patternMatches" in "org.jboss.metadata.MethodAttributes" just stops at the first wildcard ("*") found and assumes that match is ok. Either this is a bug or the documentation ("http://docs.jboss.com/jbossas/guides/j2eeguide/r2/en/html_single/#d0e11084") should be changed and clearly inform that the wildcard must be the last character. If you specify for example "*get*" than all methods will be matched.... -- 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

15 years, 2 months

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-8443) BaseClassLoader leaks instances on redeploy

by Stan Silvert (JIRA)

BaseClassLoader leaks instances on redeploy ------------------------------------------- Key: JBAS-8443 URL: https://jira.jboss.org/browse/JBAS-8443 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: 6.0.0.M4 Reporter: Stan Silvert Assignee: Ales Justin The instance count for org.jboss.classloader.spi.base.BaseClassLoader grows by one with each redeploy. These instances are not GC'd, and they eventually cause OOM PermGen errors if you undeploy/deploy several times. -- 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, 2 months

4
7
0 / 0

[JBoss JIRA] Created: (SECURITY-344) Error decrypting datasource password with SecureIdentityLoginModule

by Marcus Moyses (JIRA)

Error decrypting datasource password with SecureIdentityLoginModule ------------------------------------------------------------------- Key: SECURITY-344 URL: https://jira.jboss.org/jira/browse/SECURITY-344 Project: JBoss Security and Identity Management Issue Type: Bug Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: 2.0.2.SP3 Reporter: Marcus Moyses Assignee: Marcus Moyses Fix For: 2.0.2.SP5 During password decryption using SecureIdentityLoginModule there could be an error due to missing leading zeros for certain passwords. This error might appear in the log: [SecureIdentityLoginModule] Failed to decode password javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher at com.sun.crypto.provider.SunJCE_h.b(DashoA12275) at com.sun.crypto.provider.SunJCE_h.b(DashoA12275) at com.sun.crypto.provider.BlowfishCipher.engineDoFinal(DashoA12275) at javax.crypto.Cipher.doFinal(DashoA12275) at org.jboss.resource.security.SecureIdentityLoginModule.decode(SecureIdentityLoginModule.java:173) at org.jboss.resource.security.SecureIdentityLoginModule.commit(SecureIdentityLoginModule.java:114) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) -- 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, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (SECURITY-530) Implement a TOTP Login Module

by Anil Saldhana (JIRA)

Implement a TOTP Login Module ----------------------------- Key: SECURITY-530 URL: https://jira.jboss.org/browse/SECURITY-530 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: PicketBox_v3_0_CR1 Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: PicketBox_v3_0_CR2 It should be possible for an user to enter a TOTP value from any handheld device into a text box in the login form of a web application. This login module can then validate the totp entered. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-659) unable to download archetype-catalog.xml from releases repo

by Ian Springer (JIRA)

unable to download archetype-catalog.xml from releases repo ----------------------------------------------------------- Key: JBBUILD-659 URL: https://jira.jboss.org/browse/JBBUILD-659 Project: JBoss Build System Issue Type: Bug Components: Artifact Repositories Affects Versions: Maven Repository Nexus Rollout Reporter: Ian Springer $ wget https://repository.jboss.org/nexus/content/repositories/releases/archetyp... --2010-11-02 15:28:40-- https://repository.jboss.org/nexus/content/repositories/releases/archetyp... Resolving repository.jboss.org... 10.5.105.13 Connecting to repository.jboss.org|10.5.105.13|:443... connected. HTTP request sent, awaiting response... 500 Internal Server Error 2010-11-02 15:28:42 ERROR 500: Internal Server Error. -- 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, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-4078) DeploymentManager.getAvailableModules() returns null

by Libor Kotouc (JIRA)

DeploymentManager.getAvailableModules() returns null ---------------------------------------------------- Key: JBAS-4078 URL: http://jira.jboss.com/jira/browse/JBAS-4078 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-5.0.0.Beta2 Environment: JBoss 5.0.0.beta2 trunk build 20070206, JDK 1.5.0_08 Reporter: Libor Kotouc Assigned To: Dimitris Andreadis Priority: Critical This issue blocks an integration of JBoss AS 5 into NetBeans IDE. Steps to reproduce the behavior: 1. create a simple web application and copy the .war file into the deploy directory (I used the 'default' server) 2. start JBoss server (./run.sh) 3. run the following code from a J2SE application (I added JBoss jars to the classpath): public class Main { public static void main(String[] args) { try { javax.enterprise.deploy.spi.factories.DeploymentFactory df = new org.jboss.deployment.spi.factories.DeploymentFactoryImpl(); javax.enterprise.deploy.spi.DeploymentManager dm; dm = df.getDeploymentManager("http://org.jboss.deployment/jsr88", null, null); javax.enterprise.deploy.spi.Target[] targets = dm.getTargets(); javax.enterprise.deploy.spi.TargetModuleID[] modules; modules = dm.getAvailableModules(javax.enterprise.deploy.shared.ModuleType.WAR, targets); System.out.println(targets.length + " " + targets[0]); System.out.println(modules); } catch (javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException ex) { } catch (javax.enterprise.deploy.spi.exceptions.TargetException ex) { } } } The output of System.out.println statements is: 1 org.jboss.deployment.spi.JMXTarget@161d36b null I expect the module representing the web application, but null is returned. -- 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

15 years, 3 months

4
5
0 / 0

[JBoss JIRA] Created: (JGRP-1279) ENCRYPT: algorithm provider only half implemented

by Bela Ban (JIRA)

ENCRYPT: algorithm provider only half implemented ------------------------------------------------- Key: JGRP-1279 URL: https://issues.jboss.org/browse/JGRP-1279 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.6.19, 2.12 [Dennis Reed] ENCRYPT allows the asym_provider to be specified. But it only uses it for the KeyGenerator lookup, not the Cipher lookup. And the sym_provider is hard-coded to null. Is there a reason the sym_provider isn't configurable, and that the providers aren't used for the Cipher lookups? This is causing issues for a customer, because they have an application that inserts a security provider at the beginning of the list. When JGroups first starts, it uses the default provider (BouncyCastle), but if there's a shun/reconnect after the application has inserted its provider, JGroups switches to the application's provider. And since some members are now using a different provider, they can't communicate. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-1205) Retransmitter reset does not prevent new task addition after chanel close

by Vladimir Blagojevic (JIRA)

Retransmitter reset does not prevent new task addition after chanel close ------------------------------------------------------------------------- Key: JGRP-1205 URL: https://jira.jboss.org/browse/JGRP-1205 Project: JGroups Issue Type: Bug Affects Versions: 2.9, 2.8, 2.7, 2.6.15 Reporter: Vladimir Blagojevic Assignee: Bela Ban Fix For: 2.10 Sometimes, messages are being added to the Retransmitter *after* a channel has been . This can happen if OOB messages are being passed around at the time a channel leaving a group. The problem occurs in that messages are added after Retransmitter.reset(). Normally, the timer is also stopped when the channel is disconnected, but since the Timer is shared amongst all channels, any messages added to Retransmitter after reset() just continue to be requested because the timer that those tasks were scheduled on did not die. This can be solved by either specifically stopping the Retransmitter or giving each ProtocolAdapter their own Timer which is then shutdown on channel disconnect. Michael -- 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, 3 months

4
7
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-259) Customized Infinispan CacheManager impl

by Brian Stansberry (JIRA)

Customized Infinispan CacheManager impl --------------------------------------- Key: JBCLUSTER-259 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-259 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Server-Cache-ISPN Reporter: Brian Stansberry Fix For: HA-Server-Cache-ISPN 1.0.0.Final If necessary. ---- Inject ChannelFactory ---- Figure how to configure desired channel in Infinispan config ---- Figure how to inject desired channel after creating cache Aliasing if not supported yet via ISPN-316 Check for other AS 5 CacheManager features useful for retaining, e.g. not stopping caches at CacheManager stop? -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-283) Remove support for integrating with standalone Tomcat

by Brian Stansberry (JIRA)

Remove support for integrating with standalone Tomcat ----------------------------------------------------- Key: JBCLUSTER-283 URL: https://jira.jboss.org/browse/JBCLUSTER-283 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Server-Cache-SPI Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: HA-Server-Cache-SPI 3.0.0.Final Standalone tomcat support is years old, has never been finished and is getting in the way of clean implementations of new features. -- 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, 3 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 January 2011