February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-842) The current clustered ConnectionFactory is not apropriate for use with an MDB container.

by Ovidiu Feodorov (JIRA)

The current clustered ConnectionFactory is not apropriate for use with an MDB container. ---------------------------------------------------------------------------------------- Key: JBMESSAGING-842 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-842 Project: JBoss Messaging Issue Type: Bug Components: AS Integration Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Critical Fix For: 1.2.0.CR1 An MDB creates several connections during its deployment. If using a load-balancing clustered ConnectionFactory, they'll end up on different cluster nodes, which is precisely what the MDB container doesn't need. -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1240) Nested pages issue in JS for navigation

by Stephen Westbom (JIRA)

Nested pages issue in JS for navigation --------------------------------------- Key: JBPORTAL-1240 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1240 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.Alpha2 Environment: Windows XP Reporter: Stephen Westbom Assigned To: Julien Viet Nested pages issue in JS for navigation. If you nest pages in the {project name}_object.xml the nested menus will not show up for the current page, only for the non-current pages. -- 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, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1265) Theme and tab header are not applied on maximized windows

by Thomas Heute (JIRA)

Theme and tab header are not applied on maximized windows --------------------------------------------------------- Key: JBPORTAL-1265 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1265 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.Alpha2 Reporter: Thomas Heute Assigned To: Julien Viet Fix For: 2.6.Beta1 When maximizing a window, the portal theme falls back to the default one, the tabs and links also disappear from the header -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBAS-1824) JACC: <role-name>*</role-name> in web.xml

by Anil Saldhana (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1824?page=comments#action_12353191 ] Anil Saldhana commented on JBAS-1824: ------------------------------------- Promised a customer long ago. This is a simple issue that will go into CR1. > JACC: <role-name>*</role-name> in web.xml > ----------------------------------------- > > Key: JBAS-1824 > URL: http://jira.jboss.com/jira/browse/JBAS-1824 > Project: JBoss Application Server > Issue Type: Feature Request > Components: Security > Affects Versions: JBossAS-4.0.2 Final > Environment: - > Reporter: Roland R?z > Assigned To: Anil Saldhana > Priority: Minor > Fix For: JBossAS-4.2.0.CR1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > In some cases I wish to do authentication without authorisation. For example everybody has access to my web-resource, but I want to know who she/he is. > Therefore the accessing user must login. > So my web.xml contains the following snippet: > ... > <security-constraint> > <web-resource-collection> > <web-resource-name>Protected Helloworld example</web-resource-name> > <description/> > <url-pattern>/servlet/HelloWorldExample</url-pattern> > <http-method>POST</http-method> > <http-method>GET</http-method> > </web-resource-collection> > <auth-constraint> > <role-name>*</role-name> > </auth-constraint> > </security-constraint> > <login-config> > <auth-method>BASIC</auth-method> > <realm-name>public</realm-name> > </login-config> > ... > The web app runs with this configuration in Tomcat 5.5.8 standalone but not in Jboss. > To run it in Jboss I have to add the following element: > <security-role> > <role-name>aRole</role-name> > </security-role> > The JACC spec (section 3.1.3.1, paragraph 3)states : > " ?. When an auth-constraint names the reserved role-name, "*", all of the patterns in the containing security-constraint must be combined with all of the roles defined in the web application." > JBoss implemented this by combining all of the patterns with all roles defined in the web.xml and assumes that each role has to be defined in the web.xml. > But the web applications roles are probably defined in other files than the web.xml. In our case we use JACC with an external authentication provider. And each time, the roles changes, I also would have to modify the web.xml. > It is desirable if the auth-contraint with the role-name "*" acceppts "all" roles and not only those that are defined in the web.xml. > Or is this a JACC spec issue? > Regards, > Andrea -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2635) Performance enhancements to JDBC2 CMP

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2635?page=all ] Dimitris Andreadis updated JBAS-2635: ------------------------------------- Fix Version/s: (was: JBossAS-4.2.0.CR1) Unscheduled - There are no cycles to fully evaluate the patch or do performance optimizations on the old cmp engine. If someone else what's to take this, go ahead. > Performance enhancements to JDBC2 CMP > ------------------------------------- > > Key: JBAS-2635 > URL: http://jira.jboss.com/jira/browse/JBAS-2635 > Project: JBoss Application Server > Issue Type: Patch > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-4.0.3 SP1 > Environment: Linux/Windows > Reporter: David Strong > Assigned To: Alexey Loubyansky > Priority: Minor > Attachments: jboss-jdbc2-patches.tar.gz > > > Unisys Patches For JDBC2 > Unisys have made some patches to four of the JDBC2 files: > $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/bridge/JDBCCMPFieldBridge2.java > $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/EntityTable.java > $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/PartitionedTableCache.java > $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/TableCache.java > All changes are tagged with /// UIS and some brief comments. Some changes have been made to JDBCCMPFieldBridge2.java and EntityTable.java to cache frequently used objects such as entity fields and primary keys. > The majority of changes relate to the interaction between EntityTable.java, PartitionedTableCache.java and TableCache.java. > Consider the following situation. An EJB requires a row from the database. EntityTable.java contains an inner View class. The View seems to be instantiated per transaction. The View is asked to locate the row in question. First, the View looks to an internal cache. If the row exists, it is returned. If not, PartitionedTableCache.java and then TableCache.java are used to determine if the row is in their cache. If the row exists, it is returned. If not, the View loads the row from the database and places it into its own cache. At the end of the transaction in question, the View flushes its cache into the TableCache.java cache. The next transaction along will get a new View and the process starts again. > This mechanism is adequate if rows are being updated. In this case, TableCache.java will hold a clean copy of the row, the View will update a copy of the row and then copy it back to TableCache.java in the case of a commit or not in the case of a rollback. > However, in the case of a read only transaction, there is a lot of wasted overhead with object creation and copies that don?t really need to occur. > The UIS patches to EntityTable.java, PartitionedTableCache.java and TableCache.java provide a prototype that does not make excessive copies of objects when a bean is marked as read only. > Another patch to this area allows rows, from read only tables, to be preloaded at startup time. This allows the code to access caches without locking them and does not require the row promotion logic within TableCache.java to be executed. This prototype should only be used for small, static tables. > The patches are enabled when the <read-only-cache> and <pre-load-rows> elements appear in the jboss.xml file for a specific EJB. A sample jboss.xml file is shown below: > <?xml version="1.0" encoding="ISO-8859-1"?> > <!DOCTYPE jboss PUBLIC > "-//JBoss//DTD JBOSS 3.2//EN" > "http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd"> > <jboss> > <enterprise-beans> > <entity> > <ejb-name>SomeEJB</ejb-name> > <configuration-name>SomeEJB</configuration-name> > </entity> > </enterprise-beans> > <container-configurations> > <container-configuration extends="Standard CMP 2.x EntityBean"> > <container-name>SomeEJB</container-name> > <container-invoker-conf> > <Optimized>True</Optimized> > </container-invoker-conf> > <container-cache-conf> > <cache-policy-conf> > <min-capacity>100</min-capacity> > <max-capacity>100</max-capacity> > </cache-policy-conf> > <cache-policy-conf-other> > <partitions>1</partitions> > <read-only-cache>true</read-only-cache> > <pre-load-cache>true</pre-load-cache> > </cache-policy-conf-other> > </container-cache-conf> > </container-configuration> > </container-configurations> > </jboss> > Although the prototype code seems to work well ? we?ve observed a 20% improvement in throughput in some test cases as well as lower CPU usage, better response times, less garbage created - we believe a better scheme could be used for read only transactions of this nature. We will investigate the possibility of using a different View for read only transactions, possibly reusing the same View for all read only transactions. The intent would be to provide caching at the View level only, to further reduce the overhead of unnecessary objection creation and copies. > Another area of further investigation would be focused on the use of common caches between related entities. At present, it looks like entity relationships cause the same tables to be cached by different instances of EntityTable.java. -- 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, 2 months

1
0
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, 2 months

4
7
0 / 0

[JBoss JIRA] Commented: (JBAS-2635) Performance enhancements to JDBC2 CMP

by Alexey Loubyansky (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2635?page=comments#action_12353186 ] Alexey Loubyansky commented on JBAS-2635: ----------------------------------------- I wouldn't apply it as-is. As David says it's more like a prototype. I think the ideas of the read-only logic that reduces cache locking make sense. If performance improvements of our cmp2 impl are still the priority then we should look deeper into this. > Performance enhancements to JDBC2 CMP > ------------------------------------- > > Key: JBAS-2635 > URL: http://jira.jboss.com/jira/browse/JBAS-2635 > Project: JBoss Application Server > Issue Type: Patch > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-4.0.3 SP1 > Environment: Linux/Windows > Reporter: David Strong > Assigned To: Alexey Loubyansky > Priority: Minor > Fix For: JBossAS-4.2.0.CR1 > > Attachments: jboss-jdbc2-patches.tar.gz > > > Unisys Patches For JDBC2 > Unisys have made some patches to four of the JDBC2 files: > $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/bridge/JDBCCMPFieldBridge2.java > $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/EntityTable.java > $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/PartitionedTableCache.java > $JBOSS_HOME/server/src/main/org/jboss/ejb/plugins/cmp/jdbc2/schema/TableCache.java > All changes are tagged with /// UIS and some brief comments. Some changes have been made to JDBCCMPFieldBridge2.java and EntityTable.java to cache frequently used objects such as entity fields and primary keys. > The majority of changes relate to the interaction between EntityTable.java, PartitionedTableCache.java and TableCache.java. > Consider the following situation. An EJB requires a row from the database. EntityTable.java contains an inner View class. The View seems to be instantiated per transaction. The View is asked to locate the row in question. First, the View looks to an internal cache. If the row exists, it is returned. If not, PartitionedTableCache.java and then TableCache.java are used to determine if the row is in their cache. If the row exists, it is returned. If not, the View loads the row from the database and places it into its own cache. At the end of the transaction in question, the View flushes its cache into the TableCache.java cache. The next transaction along will get a new View and the process starts again. > This mechanism is adequate if rows are being updated. In this case, TableCache.java will hold a clean copy of the row, the View will update a copy of the row and then copy it back to TableCache.java in the case of a commit or not in the case of a rollback. > However, in the case of a read only transaction, there is a lot of wasted overhead with object creation and copies that don?t really need to occur. > The UIS patches to EntityTable.java, PartitionedTableCache.java and TableCache.java provide a prototype that does not make excessive copies of objects when a bean is marked as read only. > Another patch to this area allows rows, from read only tables, to be preloaded at startup time. This allows the code to access caches without locking them and does not require the row promotion logic within TableCache.java to be executed. This prototype should only be used for small, static tables. > The patches are enabled when the <read-only-cache> and <pre-load-rows> elements appear in the jboss.xml file for a specific EJB. A sample jboss.xml file is shown below: > <?xml version="1.0" encoding="ISO-8859-1"?> > <!DOCTYPE jboss PUBLIC > "-//JBoss//DTD JBOSS 3.2//EN" > "http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd"> > <jboss> > <enterprise-beans> > <entity> > <ejb-name>SomeEJB</ejb-name> > <configuration-name>SomeEJB</configuration-name> > </entity> > </enterprise-beans> > <container-configurations> > <container-configuration extends="Standard CMP 2.x EntityBean"> > <container-name>SomeEJB</container-name> > <container-invoker-conf> > <Optimized>True</Optimized> > </container-invoker-conf> > <container-cache-conf> > <cache-policy-conf> > <min-capacity>100</min-capacity> > <max-capacity>100</max-capacity> > </cache-policy-conf> > <cache-policy-conf-other> > <partitions>1</partitions> > <read-only-cache>true</read-only-cache> > <pre-load-cache>true</pre-load-cache> > </cache-policy-conf-other> > </container-cache-conf> > </container-configuration> > </container-configurations> > </jboss> > Although the prototype code seems to work well ? we?ve observed a 20% improvement in throughput in some test cases as well as lower CPU usage, better response times, less garbage created - we believe a better scheme could be used for read only transactions of this nature. We will investigate the possibility of using a different View for read only transactions, possibly reusing the same View for all read only transactions. The intent would be to provide caching at the View level only, to further reduce the overhead of unnecessary objection creation and copies. > Another area of further investigation would be focused on the use of common caches between related entities. At present, it looks like entity relationships cause the same tables to be cached by different instances of EntityTable.java. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3887) Upgrade Javassist to v3.4.0

by Dimitris Andreadis (JIRA)

Upgrade Javassist to v3.4.0 --------------------------- Key: JBAS-3887 URL: http://jira.jboss.com/jira/browse/JBAS-3887 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Other Reporter: Dimitris Andreadis Fix For: JBossAS-4.2.0.CR1 Upgrade to the latest Javassist -- 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, 2 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-4099) Upgrade AOP to 1.5.4.GA

by Kabir Khan (JIRA)

Upgrade AOP to 1.5.4.GA ----------------------- Key: JBAS-4099 URL: http://jira.jboss.com/jira/browse/JBAS-4099 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: AOP Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: JBossAS-4.2.0.CR1 -- 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, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-4098) Upgrade javassist to 3.5.0.CR1

by Kabir Khan (JIRA)

Upgrade javassist to 3.5.0.CR1 ------------------------------ Key: JBAS-4098 URL: http://jira.jboss.com/jira/browse/JBAS-4098 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: AOP Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: JBossAS-4.2.0.CR1 -- 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, 2 months

2
3
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 2007