July 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - What replaces determineResolvedJndiName?

by scott.stark＠jboss.org

Where are we at in terms of a comprehensive jndi resolution interface? The determineResolvedJndiName methods of the JBossEnterpriseBeanMetaData are deprecated, what replaces them? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165977#4165977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165977

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: appclient remote home regression

by scott.stark＠jboss.org

So | // Determine the jndi name for the reference interface | String iface = getInterface(ref); | //LegacyEjb3JndiPolicy policy = new LegacyEjb3JndiPolicy(); | String containerJndiName = target.getBeanMetaData().determineJndiName(); | if(containerJndiName != null) | ref.setResolvedJndiName(containerJndiName); | and the metadata determineJndiName() is implemented by JBossSessionPolicyDecorator.determineJndiName(), which calls JBossSessionPolicyDecorator.determineResolvedRemoteBusinessDefaultJndiName(). This is for an ejb3x remote reference, not an ejb2x remote home reference. The call to getInterface(ref) is unused. The resulting iface should be getting passed into determineResolvedJndiName(String iface) so the iface can be recognized as a home rather than a remote business interface. What we need is a comprehensive metadata unit test that takes each type of ejb reference metadata, and resolves a jndi name for both ejb2x, ejb3x bean metadata. This is what the MappedReferenceMetaDataResolverDeployer needs to set each reference resolved jndi name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165976#4165976 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165976

17 years, 8 months

1
0
0 / 0

[Design of POJO Server] - appclient remote home regression

by scott.stark＠jboss.org

I'm seeing the same 3 errors in the appclient tck tests as currently seen in the tck runs: http://hudson.qa.jboss.com/hudson/view/TCK5/job/tck5-appclient/lastBuild/... in the mc/vfs appclient work I'm doing, so its just a general regression in the jndi name of the ejb remote home. The home is resolving to the descriptor jndi-name, but the home is bound under ear-name/bean-name/home. These tests are effectively deploying ejb2.x beans as ejb3.x beans(no annotations, just a v3 ejb-jar.xml), and a j2ee 1.4 or earlier client is linking to the ejb using its bean name. Its a descriptor ejb-ref with a remote/home specified. The issue is that the MappedReferenceMetaDataResolverDeployer will have to resolve the ejb-ref differently based on whether the target ejb is a 2.x or 3.x. We should have this info available in the binding policy, so I need to see what is going on with not using it. I guess its just that the server specified binding policy is not in synch with the current ejb3 behavior. Is the ejb3 proxy layer using the deployment binding policy for all proxies yet? Looking at the code this does not appear to be the case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165971#4165971 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165971

17 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by bstansberry＠jboss.com

Sounds like activity on the entity cache should be almost entirely reads, which should scale. Doesn't sound like there would even be that many cases of db read + cache write after an initial warmup period. Is the web session clustered? If so, be sure to use buddy replication for the web session cache or the session replication will inhibit scalability. Do the use_query_cache=false bit first though so we know whether that has an effect. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165968#4165968 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165968

17 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by prabhat.jha＠jboss.com

Portal world is bit different. Although there is no explicit entity stuff, portal stores which portal page contains which porlet in database. A request to such page usually results into a hit to database along with check if anonymous user has access to that page and porltet or not. I already worked with the team on optimizing DB calls in non clustered as well as clustered (one node) setup. What we are trying to achieve is take the numbers from one node as base line and see how it gets as we add nodes to cluster. I hope this clarifies few things. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165966#4165966 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165966

17 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by bstansberry＠jboss.com

I don't see anything there that involves entities; looks like a pure session replication test. Is your session replication cache configured for buddy replication? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165962#4165962 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165962

17 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by prabhat.jha＠jboss.com

We can leave CMS out completely as my tests don't use any CMS component. CMS classes are loaded on start up and that's about it. A very simple portlet that I am using to test is at http://anonsvn.jboss.org/repos/qa/portal/failover-test/failover-test/src/... . This is very similar to what Dominik used to test scalability in EAP. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165955#4165955 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165955

17 years, 8 months

1
0
0 / 0

[Design of JBoss Portal] - Re: portal clustering problem when using optimistic locking

by bstansberry＠jboss.com

If you are not caching queries, that's good. We're on the same page on your config, which can now be applied to the CMS cache. If that and use_query_cache=false don't resolve your issue there's either something I'm missing in how JBC handles invalidation in the Hibernate "put" use case (db read + cache write) or your testing is doing a really high number of entity creations/updates (which isn't going to scale). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165951#4165951 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165951

17 years, 8 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: JBOSS 5.0 + SQL SERVER 2005 = ClassNotFoundException: co

by szymanski

I'm so sorry...but I need some help and a possible solution for that problem. Sorry :( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165950#4165950 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165950

17 years, 8 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: JBOSS 5.0 + SQL SERVER 2005 = ClassNotFoundException: co

by PeterJ

Please do not post user questions in a developer's forum! Please do not post the same question in multiple forums! http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165947 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4165948#4165948 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4165948

17 years, 8 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-dev-forums July 2008