July 2006 - jboss-jira - Jboss List Archives

[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

17 years, 4 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

17 years, 4 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

17 years, 4 months

6
10
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

17 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-957) Mutliple versions of languages in language drop-down in user profile

by Chris Laprun (JIRA)

Mutliple versions of languages in language drop-down in user profile -------------------------------------------------------------------- Key: JBPORTAL-957 URL: http://jira.jboss.com/jira/browse/JBPORTAL-957 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Portlet Affects Versions: 2.4 Final Reporter: Chris Laprun Priority: Minor Fix For: 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

17 years, 4 months

4
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-946) Window changes in admin ui not immediate

by Roy Russo (JIRA)

Window changes in admin ui not immediate ---------------------------------------- Key: JBPORTAL-946 URL: http://jira.jboss.com/jira/browse/JBPORTAL-946 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.4 Final Reporter: Roy Russo Assigned To: Julien Viet Moving windows via the ui do not register immediatley when the page refreshes. You must log in again to see the changes. -- 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

17 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-693) TreeCache configuration bombs with InvocationTargetException when JVM locale is set to Turkish.

by Yasar Safkan (JIRA)

TreeCache configuration bombs with InvocationTargetException when JVM locale is set to Turkish. ----------------------------------------------------------------------------------------------- Key: JBCACHE-693 URL: http://jira.jboss.com/jira/browse/JBCACHE-693 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Environment: Tested on Linux, using Resin 3.0.14 with Hibernate 3. Reporter: Yasar Safkan Assigned To: Manik Surtani When the parameters: -Duser.language=tr -Duser.country=TR are passed to the JVM, the AppServer startup bombs when it tires to configure TreeCache using treecache.xml. Seems that it reads the value fine, but thinks the value is invalid for some reason. My best guess is this stems from the way the letters i and I are handled in Turkish. If there is any upper/lowercase conversion code within JBossCache, these letters are handled funny, thus string constants like READ_COMMITED are not recognized. The fix will probably be to use upper/lowercase conversion by specifying a character set in the JBossCache code, and not relying on the JVM defaults. The JVM itself had a similar bug, which prevented encrytion from working under these same conditions. -- 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

17 years, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAOP-276) Construct to only match classes within a package

by Kabir Khan (JIRA)

Construct to only match classes within a package ------------------------------------------------ Key: JBAOP-276 URL: http://jira.jboss.com/jira/browse/JBAOP-276 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0 field(* org.jboss.*->i) matches both org.jboss.Foo.i and org.jboss.sub.sub.sub.Bar.i Should be able to narrow this down to just the package, e.g. field(* $package{org.jboss}->i) matches onlyu org.jboss.Foo.i and org.jboss.Bar.i -- 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

17 years, 4 months

1
6
0 / 0

[JBoss JIRA] Created: (JBCOMMON-1) ArchiveBrowser does not handle Windows directories with whitespace

by Emmanuel Bernard (JIRA)

ArchiveBrowser does not handle Windows directories with whitespace ------------------------------------------------------------------ Key: JBCOMMON-1 URL: http://jira.jboss.com/jira/browse/JBCOMMON-1 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Emmanuel Bernard Assigned To: Emmanuel Bernard Priority: Minor new File(url.toString()) fails on white spaced directories -- 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

17 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-3398) Non exploded sar containing war cannot undeploy the war file properly

by Julien Viet (JIRA)

Non exploded sar containing war cannot undeploy the war file properly --------------------------------------------------------------------- Key: JBAS-3398 URL: http://jira.jboss.com/jira/browse/JBAS-3398 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final Environment: JBoss-4.0.4.GA MacOSX Tiger Java 1.4.2 Reporter: Julien Viet Assigned To: Dimitris Andreadis Fix For: JBossAS-4.0.5.CR1, JBossAS-5.0.0.GA A sar file containing a war file non exploded is dropped in AS before startup. Start JBoss Shutdown JBoss The MainDeployer wants to stop() / destroy() the war file. The Web deployer is already gone and it produces an javax.management.InstanceNotFoundException when it tries to stop() / destroy() the war deployer Because the war is nested in a sar file, the web deployer is undeployed before the sar containing the war is undeployed. Note : this does not happen with exploded sar (like http invoker sar that contains the invoker.war) because the war is added to the MainDeployer.deploymentList list. This does not happen with non exploded because the war file is not in the local directory but rather in tmp and thus does not get added to the deployment list. Here are some field values : the string used to discriminate wether it's in local or tmp - file:/Users/julien/java/jboss-4.0.4.GA/server/default/tmp/deploy/ a war in non exploded sar - file:/Users/julien/java/jboss-4.0.4.GA/server/default/tmp/deploy/tmp51485jboss-portal.sar-contents/portal-core.war invoker.war in exploded sar - file:/Users/julien/java/jboss-4.0.4.GA/server/default/deploy/http-invoker.sar/invoker.war/ -- 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

17 years, 5 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2006