March 2007 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Re: SFSB proxy creation process incorrectly routed locally

by bstansberry＠jboss.com

One possible solution -- the target id for the ProxyFactory can't be its JNDI name. It should be the ObjectName of the container + another attribute. For clustered beans, the partition name should be included as well. Problem with this is the doesn't deal with the EJBTHREE-773 issue -- apparently customers wanted to deploy the same bean in the same package on node0 and node1. But if a client on node0 specifically looks up the bean on node1's JNDI, the call should go to the node1 bean. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031366#4031366 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031366

19 years

1
0
0 / 0

[Design of EJB 3.0] - SFSB proxy creation process incorrectly routed locally

by bstansberry＠jboss.com

Related discussions: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=101220 http://jira.jboss.com/jira/browse/EJBTHREE-773 Problem I found while testing my EJBTHREE-881 fix: Say you have two completely unrelated SFSBs, Bean0 and Bean1, deployed on two different servers, node0 and node1. The only common point between Bean0 and Bean1 is they both are bound in JNDI under "StatefulBeanRemote". Otherwise they are completely unrelated. Client on node0 then contacts the JNDI server on node1 and does a lookup of "StatefulBeanRemote" expecting to get a proxy for Bean1. The SFSB proxy-creation process will end up being routed locally to the proxy factory for Bean0. Wrong! Problem is this: 1) When client does an SFSB lookup, they don't directly download the SFSB proxy. Instead they download a proxy to the bean's ProxyFactory. That proxy then makes a remoting RPC back to the remote server to get the SFSB proxy. See o.j.ejb3.JndiProxyFactory. 2) The proxy to the remote ProxyFactory includes o.j.aspects.remoting.IsLocalnterceptor. That interceptor will bypass the remote call and invoke locally if the aop Dispatcher has a target registered with the same id as the target id associated with the call. 3) For calls made by the proxy to the remote ProxyFactory, the target id is the jndiName of the bean (plus a constant). So, if an unrelated target is registered locally with the same JNDI name, there's going to be confusion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031364#4031364 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031364

19 years

1
0
0 / 0

[Design of POJO Server] - Re: vfs issue?

by scott.stark＠jboss.org

If its making the assumption that java.io.File is a valid means to access the contents of a deployment, yes, that is wrong. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031342#4031342 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031342

19 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: MethodInvocation.getArguments return value for 0 argumen

by clebert.suconic＠jboss.com

I will make the code more robust as Scott sugested... We were just discussing if this is right or wrong. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031340#4031340 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031340

19 years

1
0
0 / 0

[Design of POJO Server] - Re: vfs issue?

by charles.crouch＠jboss.com

Ok, so just to be clear. You're saying this is something that needs to be fixed in Seam? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031336#4031336 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031336

19 years

1
0
0 / 0

[Design of POJO Server] - Re: vfs issue?

by scott.stark＠jboss.org

Use of a File is not valid. There is the VFS and nothing else. The url looks to be pointing to a jar nested inside of an ear which will not have a valid File representation. The input stream from the vfs url is what needs to be passed to the ZipInputStream. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031326#4031326 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031326

19 years

1
0
0 / 0

[Design of POJO Server] - vfs issue?

by charles.crouch＠jboss.com

Is this a VFS issue? http://jira.jboss.com/jira/browse/JBAS-4241 Cheers Charles View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031321#4031321 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031321

19 years

1
0
0 / 0

[Design of POJO Server] - Re: trunk testsuite status

by charles.crouch＠jboss.com

Anil I don't think this is anything to do with Scott's environment, cruisecontrol is also running the /trunk testsuite to completion: http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-testsuite-1.5?l... You can see the "(JACC)" tests running and failing. The last checkin cruisecontrol included was r61639. According to http://fisheye.jboss.com/changelog/JBossAS/ the only commit since then to trunk was 61651 by scott.stark(a)jboss.org on 24 March 2007, 00:47:02 -0400 (8 hours ago) Correct the web app object name for the root context | | trunk/server/src/main/org/jboss/web/deployers/AbstractWarDeployer.java | which doesn't look like it should cause the problems you are seeing. Cheers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031276#4031276 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031276

19 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: MethodInvocation.getArguments return value for 0 argumen

by kabir.khan＠jboss.com

If it is an easy change, I think we should put it back the way it was. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031275#4031275 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031275

19 years

1
0
0 / 0

[Design of Kosmos] - SVN portlet timeout error

by mega

Hi, there, I am trying to monitor several SVN projects. Some svn repostiories' "svn status data" could be generated, but some failed. It is reported "time out". (i already changed the "TransactionTimeout" to 3000 in the "jboss-service.xml" file) Did you happen to meet the same problems? Would you please give me some suggestions? Thanks in advance. Below is the error log: 20:19:34,898 INFO [SvnMonitoringPortlet] Viewing... 20:19:35,054 INFO [STDOUT] 20:19:35,053 INFO [MethodResultCacheInterceptor] Cache-miss: reloading "hu.midori.kosmos.server.svn.SvnServiceImpl.getRepositories.http://user:passwd@sh-svn.sh.xxx.com/ssg_repos/svn_WML/WML/"... 20:19:35,140 INFO [STDOUT] 20:19:35,140 INFO [SvnServiceImpl] Analyzing log of "http://user:passwd@sh-svn.sh.xxx.com/ssg_repos/svn_WML/WML" repository... 20:19:55,506 INFO [STDOUT] 20:19:55,506 INFO [SvnServiceImpl] 485 log-entries received. 20:19:55,507 INFO [STDOUT] 20:19:55,507 ERROR [SvnServiceImpl] Skipping invalid entry (no author) 20:19:56,253 INFO [STDOUT] 20:19:56,253 INFO [SvnServiceImpl] Analyzing content of "http://user:passwd@sh-svn.sh.xxx.com/ssg_repos/svn_WML/WML" repository... 21:09:34,934 WARN [TransactionImpl] Transaction TransactionImpl:XidImpl[FormatId=257, GlobalId=silc2003/137, BranchQual=, localId=137] timed out. status=STATUS_ACTIVE View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4031273#4031273 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4031273

19 years

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 March 2007