February 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBESB-193) Need support for notification generatoin from within ActionProcessor.process method

by Tom Fennelly (JIRA)

Need support for notification generatoin from within ActionProcessor.process method ----------------------------------------------------------------------------------- Key: JBESB-193 URL: http://jira.jboss.com/jira/browse/JBESB-193 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.1 Reporter: Tom Fennelly Assigned To: Mark Little Fix For: 4.1 In version 4.0, the Action Processing pipeline management code raises notifications in response to an exception from the ActionProcessor.process method. The pipeline managemnt code calls the getOkNotification (no exception) or getErrorNotification (exception) to get the notification message. For many reasons, this is a very flawed model. Notifications should be raised from within the process method by means of attaching the notifications (error or otherwise) to the message (the mechanism is a design issue). Once the process method returns, the pipline processing management code can check the message for notifications. If there are errors, it can/should (?) abort the message processing, send the error notification (by whatever notification options are configured on the listener) and signal the failure to the calling process (by whatever failure config is configured on the listener). The getOk and getErro methods can then be removed. -- 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

3 days, 12 hours

3
6
0 / 0

[JBoss JIRA] Created: (JGRP-1257) ENCRYPT protocol UnrecoverableKeyException: Given final block not properly padded

by Andres Garcia Garcia (JIRA)

ENCRYPT protocol UnrecoverableKeyException: Given final block not properly padded --------------------------------------------------------------------------------- Key: JGRP-1257 URL: https://jira.jboss.org/browse/JGRP-1257 Project: JGroups Issue Type: Bug Affects Versions: 2.11, 2.8, 2.7 Environment: Windows XP SP3, Java 1.6 Reporter: Andres Garcia Garcia Assignee: Bela Ban Recently I updated my jgroups version from 2.4.x to 2.11. Suddenly my applications thrown this exception. org.jgroups.ChannelException: unable to setup the protocol stack: Given final block not properly padded at org.jgroups.JChannel.init(JChannel.java:1574) at org.jgroups.JChannel.<init>(JChannel.java:257) at org.jgroups.JChannel.<init>(JChannel.java:240) at org.jgroups.demos.Draw.<init>(Draw.java:52) at org.jgroups.demos.Draw.main(Draw.java:141) Caused by: java.security.UnrecoverableKeyException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_z.a(DashoA13*..) at com.sun.crypto.provider.JceKeyStore.engineGetKey(DashoA13*..) at java.security.KeyStore.getKey(Unknown Source) at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:269) at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:231) at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:641) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:468) at org.jgroups.JChannel.init(JChannel.java:1570) ... 4 more The ENCRYPT protocol config is <ENCRYPT sym_init="448" sym_algorithm="Blowfish" encrypt_entire_message="true" key_store_name="cloudencrypt.keystore" store_password="password" alias="test"/> I tested the same code with different versions. 2.6.15 GA is the last working version, and every version I tested from 2.7 GA to 2.11 GA throw the same exception. I made a little use case with it. Maybe I am missing something? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

5 days, 16 hours

3
9
0 / 0

[JBoss JIRA] Created: (JBFORUMS-109) BBCode support for standalone version

by Ryszard Kozmik (JIRA)

BBCode support for standalone version ------------------------------------- Key: JBFORUMS-109 URL: http://jira.jboss.com/jira/browse/JBFORUMS-109 Project: JBoss Forums Issue Type: Task Components: Forum Enhancements Reporter: Ryszard Kozmik Fix For: 1.0.0 Alpha BBCode parser is now working only in portal environment. We need make it work as a standalone too. -- 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

1 month, 3 weeks

4
5
0 / 0

[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender

by Bela Ban (JIRA)

Optimization: make threads return immediately if NAKACK has another active thread for the same sender ----------------------------------------------------------------------------------------------------- Key: JGRP-457 URL: http://jira.jboss.com/jira/browse/JGRP-457 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up. If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock. The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool. -- 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

3 months, 1 week

2
3
0 / 0

[JBoss JIRA] Created: (RELOADED-8) Create a JSR-250 compliant injection framework on top of VDF

by Carlo de Wolf (JIRA)

Create a JSR-250 compliant injection framework on top of VDF ------------------------------------------------------------ Key: RELOADED-8 URL: https://jira.jboss.org/jira/browse/RELOADED-8 Project: JBoss Reloaded Issue Type: Feature Request Components: injection Affects Versions: injection-0.1.0 Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- 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, 1 month

2
7
0 / 0

[JBoss JIRA] Created: (JBAS-7882) Wrong provider code base for security provider included in packed ear

by Petr H (JIRA)

Wrong provider code base for security provider included in packed ear --------------------------------------------------------------------- Key: JBAS-7882 URL: https://jira.jboss.org/jira/browse/JBAS-7882 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: VFS Affects Versions: JBossAS-6.0.0.M2, JBossAS-5.1.0.GA Environment: Any OS, JDK 5 and 6, JBoss AS 5.1.0 and 6.0.0.M2 Reporter: Petr H We've got applications which uses the IAIK JCE provider (http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/JCA-JCE) whose library is included directly in our application. On JBoss AS 5 and later, we can't use this provider as usually. The new VFS mechanism seems to break the path determination to the IAIK provider library (needed to determine provider code base) - it still points into the ear/war structure inside the server deploy directory but as all this is packed into one ear file, the provider verification.fails because of unsigned ear/war and thus the following exception is thrown: 2010-04-01 15:04:20,890 ERROR [STDERR] (http-0.0.0.0-8180-1) java.lang.SecurityException: JCE cannot authenticate the provider IAIK 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at iaik.test.ControllerServlet.service(ControllerServlet.java:123) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:905) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:592) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2036) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at java.lang.Thread.run(Thread.java:619) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) Caused by: java.util.jar.JarException: Cannot parse jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_c.a(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.b(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.a(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) ... 24 more This works when one of tho three mentioned workarounds is used. The most interesting of course is the third workaround for which the code base corectly points to the temporary IAIK library instance in the java.io.tmpdir: 2010-04-01 15:09:51,291 INFO [STDOUT] (http-0.0.0.0-8180-1) Provider code base: file:/tmp/nestedjar2481829661547119990.tmp I'll attach a simple testcase ear (IAIKTest.ear) which contains an evaluation version of IAIK provider library (thanks for permission to the IAIK authors) and a simple servlet (including source) which demonstrates the problem. All you need to do is to have the unrestricted JCE policy files installed in your JRE and then just put the IAIKTest.ear into the deploy directory, start the JBoss instance and access the test servlet URL in browser, for example: http://localhost:8080/IAIKTestWeb/ControllerServlet On init (which happens on start) it will register the IAIK provider On service (after you access it in browser) it will attempt to get some cipher instance and here it fails. I'll also attach two log files covering the problem: - server-default.log with default server setup where the issue occurs - server-forceVfsJar.log with jboss.vfs.forceVfsJar=true where the issue doesn't occur Also I think this is more generic problem because we had similar issues, where some jar or resource location was pointing to the packed ear/war structure inside the deploy directory instead of those VFS temporary locations, with our own code (when attemting to obtain full path) and had to perform some modifications in order to make it working. The same set of workarounds could resolve these issues as well. -- 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, 1 month

17
51
0 / 0

[JBoss JIRA] Created: (JASSIST-126) create OSGi bundle information

by Mark Struberg (JIRA)

create OSGi bundle information ------------------------------ Key: JASSIST-126 URL: https://jira.jboss.org/browse/JASSIST-126 Project: Javassist Issue Type: Feature Request Affects Versions: 3.12.0.GA Reporter: Mark Struberg Assignee: Shigeru Chiba Fix For: 3.13.0.GA Create OSGi bundle information for javassist at build time. -- 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, 2 months

5
9
0 / 0

[JBoss JIRA] Created: (JBAOP-796) Creation of ClassAdvisor must use the AspectManager equivalent to the advised class' ClassLoader

by Flavia Rainone (JIRA)

Creation of ClassAdvisor must use the AspectManager equivalent to the advised class' ClassLoader ------------------------------------------------------------------------------------------------ Key: JBAOP-796 URL: https://jira.jboss.org/browse/JBAOP-796 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.9.Alpha1 Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: 2.1.6 CP01, 2.1.9.GA, 2.2.1.GA Currently, an Advisor is created by calling AspectManager.instance().getAdvisor(). The correct is to create the advisor by calling AspectManager.instance(WovenClass.class).getAdvisor(WovenClass.class). Otherwise, the Advisor will be created as part of the AspectManager/Domain corresponding to the current context class loader: public static synchronized AspectManager instance() { return instance(Thread.currentThread().getContextClassLoader()); } In the JBoss AS environment, if the woven class is loaded during an archive deployment, this is equivalent to say that the Advisor will be erroneously created by the domain of the current deployment, instead of being created by the appropriate AspectManager/Domain instance. -- 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, 2 months

2
10
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2033) EjbReferenceResolver can't resolve service bean references

by Carlo de Wolf (JIRA)

EjbReferenceResolver can't resolve service bean references ---------------------------------------------------------- Key: EJBTHREE-2033 URL: https://jira.jboss.org/jira/browse/EJBTHREE-2033 Project: EJB 3.0 Issue Type: Bug Components: common Affects Versions: 1.1.22 Reporter: Carlo de Wolf Assignee: Carlo de Wolf org.jboss.ejb3.common.resolvers.spi.UnresolvableReferenceException: Could not resolve reference [EJB Reference: beanInterface 'org.jboss.ejb3.test.interceptors2.StatusRemote', beanName '', mappedName 'null'] in AbstractVFSDeploymentContext@790495753{file:///home/carlo/work/ejb3/testsuite/target/test-lib/interceptors2-test.jar} at org.jboss.ejb3.core.resolvers.ScopedEJBReferenceResolver.resolveEjb(ScopedEJBReferenceResolver.java:88) -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8865) caching ejb3 entities tutorial demo does not work in JBoss 6

by Leos Literak (JIRA)

caching ejb3 entities tutorial demo does not work in JBoss 6 ------------------------------------------------------------ Key: JBAS-8865 URL: https://issues.jboss.org/browse/JBAS-8865 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Reporter: Leos Literak Priority: Minor I run this demo: http://docs.jboss.org/ejb3/docs/tutorial/1.0.7/html/Caching_EJB3_Entities... in jboss 6 and it fails: Caused by: org.hibernate.HibernateException: could not instantiate RegionFactory [org.hibernate.cache.jbc2.JndiMultiplexedJBossCacheRegionFactory] at org.hibernate.cfg.SettingsFactory.createRegionFactory(SettingsFactory.java:423) [:3.6.0.Final] at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:280) [:3.6.0.Final] at org.hibernate.cfg.Configuration.buildSettingsInternal(Configuration.java:2833) [:3.6.0.Final] at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2829) [:3.6.0.Final] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1840) [:3.6.0.Final] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:902) [:3.6.0.Final] ... 78 more Caused by: java.lang.ClassNotFoundException: org.hibernate.cache.jbc2.JndiMultiplexedJBossCacheRegionFactory from BaseClassLoader@a63599{vfs:///C:/Users/llitera rver/default/conf/jboss-service.xml} at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:480) [jboss-classloader.jar:2.2.0.GA] at java.lang.ClassLoader.loadClass(ClassLoader.java:248) [:1.6.0_22] at java.lang.Class.forName0(Native Method) [:1.6.0_22] at java.lang.Class.forName(Class.java:169) [:1.6.0_22] at org.hibernate.util.ReflectHelper.classForName(ReflectHelper.java:192) [:3.6.0.Final] at org.hibernate.cfg.SettingsFactory.createRegionFactory(SettingsFactory.java:409) [:3.6.0.Final] ... 83 more please update the demo to work in current jboss, thanks -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
4
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