August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-454) refactor 'from' to use new standalone ValueHandlers

by Mark Proctor (JIRA)

refactor 'from' to use new standalone ValueHandlers --------------------------------------------------- Key: JBRULES-454 URL: http://jira.jboss.com/jira/browse/JBRULES-454 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rule Assemply/SPI Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 This involves updating RuleBuilder to now handle the building of the ValueHandlers from descr. -- 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

19 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBXB-75) Add version info to manifest

by Thomas Diesler (JIRA)

Add version info to manifest ---------------------------- Key: JBXB-75 URL: http://jira.jboss.com/jira/browse/JBXB-75 Project: JBoss XML Binding (JBossXB) Issue Type: Task Reporter: Thomas Diesler Fix For: JBossXB-1.0 -- 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

19 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-274) Don't bind to a NIC if bind address is not set

by Bela Ban (JIRA)

Don't bind to a NIC if bind address is not set ---------------------------------------------- Key: JGRP-274 URL: http://jira.jboss.com/jira/browse/JGRP-274 Project: JGroups Issue Type: Feature Request Affects Versions: 2.3 SP1, 2.3, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8, 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 If -Dbind.address or bind_addr are not set, JGroups picks the NIC to bind sockets to itself. However, especially for ServerSockets, this may not be desirable because we may want to have ServerSockets be able to receive packets through all interfaces, e.g. - NICs are 192.168.5.2, 192.168.0.2 and 127.0.0.1 (loopback) - When the bind address is set to 192.168.5.2, a given ServerSocket on port 7500 will *only accept packets from this NIC* - If someone connects to 192.168.0.2:7500 or 127.0.0.1:7500, the client will not be able to establish a connection because nobody is listening on those ports on the given NICs - If bind address was not set, this would be possible - Affected: FD_SOCK, FD_PING, TCP, TCP_NIO etc - We need to think about semantics for MulticastSockets where a wildcard address (not setting the bind address) means that the operating system picks the NIC, and *not* that the MulticastSocket will listen on all interfaces for incoming packets -- 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

19 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-277) Threadpool for timer (TimeScheduler)

by Bela Ban (JIRA)

Threadpool for timer (TimeScheduler) ------------------------------------ Key: JGRP-277 URL: http://jira.jboss.com/jira/browse/JGRP-277 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4 Current, TimeScheduler is single threaded; long running tasks delay the execution of other tasks. Introduce a thread pool and let the user configure it: e.g. single-threaded, max of 5 threads etc -- 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

19 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-3431) AuthorizationInterceptor throwing ArrayIndexOutOfBoundsException

by Anil Saldhana (JIRA)

AuthorizationInterceptor throwing ArrayIndexOutOfBoundsException ---------------------------------------------------------------- Key: JBAS-3431 URL: http://jira.jboss.com/jira/browse/JBAS-3431 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX, Security Affects Versions: JBossAS-4.0.4.GA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1 As Originally reported in JBJMX-97, the user says: ========================================================================================== I have secured the jmx-invoker-service using JAAS and the standard UsersRolesLoginModule. I am able to authenticate (basic authentication) through the web UI and manage the console using the same login config. I am getting a remote connection to the JMX server from an InitialContext that is populated with the user name and password: env.put(Context.SECURITY_PRINCIPAL, userName); env.put(Context.SECURITY_CREDENTIALS, password); Then I look up the MBeanServerConnection and try to get the MBeanInfo MBeanServerConnection server = lookup("jmx/invoker/RMIAdaptor", MBeanServerConnection.class); ObjectName name = new ObjectName(theName); MBeanInfo info = server.getMBeanInfo(name); At this point the server throws an ArrayIndexOutOfBoundsException from org.jboss.jmx.connector.invoker.AuthorizationInterceptor line 107. If I try and set an attribute: server.setAttribute(name, new Attribute("searchText", searchText)); I get instead at the same line: java.lang.ClassCastException: javax.management.Attribute at org.jboss.jmx.connector.invoker.AuthorizationInterceptor.invoke(AuthorizationInterceptor.java:107) at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:108) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) ========================================================================================== -- 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

19 years, 5 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-965) Localization Support bug

by 吴奕雄 (JIRA)

Localization Support bug ------------------------ Key: JBPORTAL-965 URL: http://jira.jboss.com/jira/browse/JBPORTAL-965 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.4 Final Environment: windowxp,ie6,charset=zh-ch Reporter: 吴奕雄 Priority: Minor Fix For: 2.0 Branch, 2.0.2 Final, 2.2 Branch, 2.4 Final -- 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

19 years, 5 months

4
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-649) Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO

by Andreas Zimmer (JIRA)

Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO --------------------------------------------------------------------------------------------------- Key: EJBTHREE-649 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD Reporter: Andreas Zimmer Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO: 20 queries/reads within transaction - 10 msecs average per query/read 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction. The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference. -- 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

19 years, 5 months

6
10
0 / 0

[JBoss JIRA] Created: (EJBTHREE-684) Ejb3 deployer does not allow method overriding with Java 1.5 Covariant return types

by Swarn Dhaliwal (JIRA)

Ejb3 deployer does not allow method overriding with Java 1.5 Covariant return types ----------------------------------------------------------------------------------- Key: EJBTHREE-684 URL: http://jira.jboss.com/jira/browse/EJBTHREE-684 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Environment: Jboss-4.0.4.GA with ejb3 installed using the installer 'jboss-4.0.4.GA-Patch1-installer.jar' Reporter: Swarn Dhaliwal We have ejb3 entities which use method overiding with java 1.5 covariant return types. The code works correctly in jboss-4.0.4rc1 with ejb3 installed using the installer. However when trying to deploy the same code in the aforementioned version a compilation exception is thrown indicating that there are duplicate methods in the class. The code looks like the following : public abstract class AbstractEntity { protected abstract Object getId(); } public class ConcreteEntity extends AbstractEntity { public String getId() { return id; } } -- 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

19 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-397) make imports and globals attributes of a rulepackage

by Michael Neale (JIRA)

make imports and globals attributes of a rulepackage ---------------------------------------------------- Key: JBRULES-397 URL: http://jira.jboss.com/jira/browse/JBRULES-397 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale For ben -- 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

19 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-652) JPA Is Requiring That Entity Bean Name Matches Table Name for @NamedQuery

by Sascha Goldsmith (JIRA)

JPA Is Requiring That Entity Bean Name Matches Table Name for @NamedQuery ------------------------------------------------------------------------- Key: EJBTHREE-652 URL: http://jira.jboss.com/jira/browse/EJBTHREE-652 Project: EJB 3.0 Issue Type: Bug Components: EJB3 Extensions Affects Versions: EJB 3.0 RC7 - FD Environment: JBoss-AS 4.0.4-GA. Reporter: Sascha Goldsmith Priority: Minor I created an entity bean with its own unique Java name. This differed from the actual table name. The following named query produces a org.hibernate.hql.ast.QuerySyntaxException when the bean is deployed: @Entity (name="ErrorAuditRecord") @Table (name="error_audit") @NamedQueries ({ @NamedQuery (name="findAllErrors", query="SELECT o FROM ErrorAuditRecord o") )) In order to get it to work, I am forced to name my Java POJO the same name as the table's name: @Entity (name="Error_Eudit") @Table (name="Error_Eudit") @NamedQueries ({ @NamedQuery (name="findAllErrors", query="SELECT o FROM Error_Audit o") )) This seems, to me, to be a bug for two reaons: 1) Why even have separate @Entity and @Table annotations (with name attributes) if the names cannot differ? 2) Devlopers are forced to name classes exactly like the table name, which produces 'ugly' Java class names (ok, minor point, but I feel it is valid) Does a subsequent EJB 3.0 release support having named queries access via entity name rather than table name? (Or more properly, without forcing one to name the entity bean with the table's name)? Best regards. You guys have done a great job with EJB 3.0 so far! Saish PS: Other users are having same issue with Hibernate as the JPA provider: http://forum.springframework.org/showthread.php?t=19737 -- 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

19 years, 5 months

2
1
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 August 2006