January 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1847) Error when creating a variable name equals the class name of the fact

by Nicolas Heron (JIRA)

Error when creating a variable name equals the class name of the fact ---------------------------------------------------------------------- Key: JBRULES-1847 URL: https://jira.jboss.org/jira/browse/JBRULES-1847 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-guvnor Affects Versions: 5.0.0.M2 Environment: Linux - Jboss 4.2.2 GA Reporter: Nicolas Heron Assignee: Mark Proctor Hello, in the BRMS, if you add a fact wih a variable name equals the class name of the fact, it does not work The good solution would be to avoid being able to create a fact variable name = class name when Calcul : Calcul() then end -- 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
3
0 / 0

[JBoss JIRA] Created: (JBRULES-842) Extract/index rule fact info on save

by Michael Neale (JIRA)

Extract/index rule fact info on save ------------------------------------ Key: JBRULES-842 URL: http://jira.jboss.com/jira/browse/JBRULES-842 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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

13 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-836) DSL expression browser

by Michael Neale (JIRA)

DSL expression browser ---------------------- Key: JBRULES-836 URL: http://jira.jboss.com/jira/browse/JBRULES-836 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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

13 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-5345) New instance of resources injected on every onMessage MDB call

by Dok Tora (JIRA)

New instance of resources injected on every onMessage MDB call -------------------------------------------------------------- Key: JBAS-5345 URL: http://jira.jboss.com/jira/browse/JBAS-5345 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.0.5.GA Environment: Java version: 1.5.0_13,Apple Computer, Inc. OS-System: Mac OS X 10.4.11,i386 Reporter: Dok Tora Assigned To: Adrian Brock Priority: Critical A new instance of an injected bean is created every time the onMessage() method of an MDB is called. Details with sample code modifications to EJBTrailBlazer for reproduction can be found here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132331 Problem was replicated in 4.0.5.GA, 4.2.1 and 4.2.2 -- 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

13 years, 8 months

5
11
0 / 0

[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

13 years, 8 months

2
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

13 years, 9 months

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

13 years, 9 months

4
5
0 / 0

[JBoss JIRA] Created: (JBREM-1074) Config Guide should clarify the HTTP transport vs Servlet

by Andrew Oliver (JIRA)

Config Guide should clarify the HTTP transport vs Servlet --------------------------------------------------------- Key: JBREM-1074 URL: https://jira.jboss.org/jira/browse/JBREM-1074 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Andrew Oliver http://docs.jboss.org/jbossas/unified_invoker/UnifiedInvoker_guide.html describes changing to use HTTP as a transport. Meaning JBoss remoting launches its own HTTP server. This is probably a pretty esoteric configuration and most people are probably looking for this: http://www.jboss.org/community/docs/DOC-9632 instead. The guide should clarify WHAT that is and where to find what you're probably REALLY looking for. (you probably don't want to run on some weird port if you're using HTTP and most installs probably run WITH tomcat which means you need to run through TC or have a totally separate IP which is pretty hard to do in most environments) -- 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, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-641) Explore data center failover for clusters at the JGroups level

by Jimmy Wilson (JIRA)

Explore data center failover for clusters at the JGroups level -------------------------------------------------------------- Key: JGRP-641 URL: http://jira.jboss.com/jira/browse/JGRP-641 Project: JGroups Issue Type: Task Affects Versions: 2.x Reporter: Jimmy Wilson Assigned To: Bela Ban Priority: Minor Explore the possibility of using a JGroups protocol (or other mechanism) to provide data center fail over. Possible use cases: * Primary/Backup * Loadbalancing w/ sticky sessions * Rolling updates * Shared data Wiki generated from this discussion (was JBossCache-specific): http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheAcrossDataCentres The forum discussion has been associated with this JIRA as well. -- 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

13 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-6307) Cross-cluster cross-talk on JBM-DATA channel

by Brian Stansberry (JIRA)

Cross-cluster cross-talk on JBM-DATA channel -------------------------------------------- Key: JBAS-6307 URL: https://jira.jboss.org/jira/browse/JBAS-6307 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, JMS (JBoss Messaging) Affects Versions: JBossAS-5.0.0.GA Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-5.0.1.CR1 The configuration syntax in the jbm-data protocol stack config's MPING.mcast_addr attribute is not understood by the JGroups parser; it's syntax only supported by the String property replacement code in jboss-common-core.jar. <MPING timeout="5000" mcast_addr="${jboss.messaging.datachanneludpaddress,jboss.partition.udpGroup:228.6.6.6}" will be evaluated by JGroups as "use value for system property 'jboss.messaging.datachanneludpaddress,jboss.partition.udpGroup', if not found use 228.6.6.6". Which results in 228.6.6.6. Fix is to replace with <MPING timeout="5000" mcast_addr="${jboss.partition.udpGroup:228.6.6.6}" in which case setting -u at AS startup will set jboss.partition.udpGroup, which JGroups will find and use. -- 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, 9 months

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2009