March 2016 - 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

5 days, 21 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

1 week, 1 day

3
9
0 / 0

[JBoss JIRA] Created: (AS7-782) Hudson/Jenkins won't work in AS7b3

by Fred Bricon (JIRA)

Hudson/Jenkins won't work in AS7b3 ---------------------------------- Key: AS7-782 URL: https://issues.jboss.org/browse/AS7-782 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.0.0.Beta3 Environment: Fedora 14, JDK 1.6.0_24, JBoss AS7 beta 3 Reporter: Fred Bricon Assignee: Jason Greene After patching AS7b3 with the latest jboss-vfs from github/master and deploying hudson ( http://search.maven.org/remotecontent?filepath=org/jvnet/hudson/main/huds...) or jenkins on AS7, an exception is thrown when accessing the homepage (or any page) : {noformat} 17:39:33,429 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/hudson-war-2.0.0].[Stapler]] (http-localhost.localdomain-127.0.0.1-8080-2) "Servlet.service()" pour la servlet Stapler a généré une exception: java.net.MalformedURLException: unknown protocol: jndi at java.net.URL.<init>(URL.java:574) [:1.6.0_24] at java.net.URL.<init>(URL.java:464) [:1.6.0_24] at java.net.URL.<init>(URL.java:413) [:1.6.0_24] at org.kohsuke.stapler.Stapler.selectResourceByLocale(Stapler.java:227) [stapler-1.155.jar:] at org.kohsuke.stapler.Stapler.openResourcePathByLocale(Stapler.java:203) [stapler-1.155.jar:] at org.kohsuke.stapler.Stapler.service(Stapler.java:145) [stapler-1.155.jar:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94) [hudson-core-2.0.0.jar:] at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86) [hudson-core-2.0.0.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) [hudson-core-2.0.0.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:162) [hudson-core-2.0.0.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) [hudson-core-2.0.0.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:388) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:658) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at java.lang.Thread.run(Thread.java:662) [:1.6.0_24] {noformat} I first mentioned this issur on irc (see http://echelog.matzon.dk/logs/browse/jboss-as7/1305151200 [13:42:43] -> [13:48:58]) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

1 week, 4 days

6
7
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, 2 weeks

2
3
0 / 0

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

9 months, 1 week

3
10
0 / 0

[JBoss JIRA] (LOGTOOL-100) Remove the hasFieldFor and hasMethodFor methods in the ReturnType interface

by James Perkins (JIRA)

James Perkins created LOGTOOL-100: ------------------------------------- Summary: Remove the hasFieldFor and hasMethodFor methods in the ReturnType interface Key: LOGTOOL-100 URL: https://issues.jboss.org/browse/LOGTOOL-100 Project: Log Tool Issue Type: Task Reporter: James Perkins Assignee: James Perkins These methods are only used in validation. The validation should just handle this internally rather than keeping extra maps around. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-71) Allow messages to have expressions resolved at code generation time

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-71?page=com.atlassian.jira.plugin... ] James Perkins updated LOGTOOL-71: --------------------------------- Fix Version/s: 2.1.0.Alpha1 (was: 1.2.2.Final) > Allow messages to have expressions resolved at code generation time > ------------------------------------------------------------------- > > Key: LOGTOOL-71 > URL: https://issues.jboss.org/browse/LOGTOOL-71 > Project: Log Tool > Issue Type: Feature Request > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Alpha1 > > > Allow messages in the {{@Message}} annotation to allow expressions in the format of: > {code} > ${property.name:default} > {code} > A warning message should be generated if the property name was not found. If not default is found an error should be generated. > The properties file needs to have the same fully qualified path and name of the interface. The properties file will not be used at runtime. There should also be an annotation processing option to allow a path to a properties file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6448) Allow configuration of testsuite such that StandardConfigsXMLValidationUnitTestCase can deal with CI testing of a core snapshot with a new kernel xsd

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-6448: -------------------------------------- Summary: Allow configuration of testsuite such that StandardConfigsXMLValidationUnitTestCase can deal with CI testing of a core snapshot with a new kernel xsd Key: WFLY-6448 URL: https://issues.jboss.org/browse/WFLY-6448 Project: WildFly Issue Type: Enhancement Components: Domain Management, Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry StandardConfigsXMLValidationUnitTestCase fails CI tests of core whenever the core snapshot under test includes a new version of the kernel xsd. See, for example, https://github.com/wildfly/wildfly-core/pull/1366. The problem is the test picks up the new xsd version as the latest, and rejects full's standard config files for using an old xsd. This makes doing xsd updates in core a hassle. Goal is to have a way to configure CI runs for core snapshots in full to avoid this problem. System property most likely. I'm quite certain my fix will be hacky! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6415) Deprecate org.jboss.as.clustering.infinispan.subsystem.ScheduledThreadPoolResourceDefinition#keepAliveTime since it has no valid meaning

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6415?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned WFLY-6415: ---------------------------------- Assignee: Paul Ferraro (was: Radoslav Husar) > Deprecate org.jboss.as.clustering.infinispan.subsystem.ScheduledThreadPoolResourceDefinition#keepAliveTime since it has no valid meaning > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6415 > URL: https://issues.jboss.org/browse/WFLY-6415 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > > {code} > * <p>While this class inherits from {@link ThreadPoolExecutor}, a few > * of the inherited tuning methods are not useful for it. In > * particular, because it acts as a fixed-sized pool using > * {@code corePoolSize} threads and an unbounded queue, adjustments > * to {@code maximumPoolSize} have no useful effect. Additionally, it > * is almost never a good idea to set {@code corePoolSize} to zero or > * use {@code allowCoreThreadTimeOut} because this may leave the pool > * without threads to handle tasks once they become eligible to run. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
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 March 2016