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

[Design of POJO Server] - Register dynamic class loading with a domain

by sguilhen＠redhat.com

We've been facing test failures in the CTS interop web vehicles related to loading the stub classes used in the tests. The ejb container succeeds at loading the stub classes because it uses the WebCL that generates these stubs on the fly. So, we've considered using a similar approach in the web container to get the stubs loaded - this logic is already available in the WebAppClassLoader but the logs show that this class loader is not being used in the tests scenarios. I first wanted to just enforce the use of this class loader again, but Scott thinks a more general solution is needed: anonymous wrote : | The ejb container to dynamic class loader behavior is very specific to the class loader in use. We should come up with a more general solution based on the new class loading domains so that any component can register its dynamic class loading with a domain. | As Adrian said, we can always include the stub classes in the vehicles war deployments to have the tests passing, but it would be good to have a more general solution in place. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157052#4157052 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157052

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Is META-INF in the classpath?

by alesj

In JBossXBHelper, should I change the code this way: | //parsed = unmarshaller.unmarshal(is, resolver); | parsed = unmarshaller.unmarshal(file.toURL().toString(), resolver); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157050#4157050 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157050

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Is META-INF in the classpath?

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : Bug report: http://jira.jboss.com/jira/browse/JBDEPLOY-47 | What would a test for this look like? Like the original post in this thread. Or if you are using schemas, something like: ejb-jar.xml | <ejb-jar xmlns="whatever" xmlns:xi="http://www.w3.org/2001/XInclude"> | <xi:include href="included.xml"/> | </ejb-jar> | included.xml | <enterprise-beans> | ... | Where included.xml is alongside ejb-jar.xml in the META-INF folder. If you pass the full uri of the enclosing (ejb-jar.)xml, the relative url (included.xml) should resolved based on that rather than the process's current directory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157048#4157048 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157048

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBPAPP-864/EJBTHREE-1109 - clustered home proxies

by bstansberry＠jboss.com

"galder.zamarreno(a)jboss.com" wrote : I think it might have been possible to retrieve the proxy factory by looking it up in JNDI and the calling any of the createProxies accordingly. I have the feeling that this solution would have indirectly gone through the Dispatcher as well. Yes, it would go through the dispatcher as well. But that becomes an internal detail of how the proxy factory works, and doesn't leak into StatefulContainer. I'm not advocating changing this for 4.x, as the usage of dispatcher is not going to change. :) But for trunk, think about it a bit. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157047#4157047 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157047

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: HDScanner exception

by dimitris＠jboss.org

I understand the issue is that the jdk's FileURLConnection is producing too many Files/FDs because it eagerly list every directory url. So it has a greater chance of runing quickly out of FDs. Normally a GC should free those, but it seems the jdk on fedora has a problem with that. I'm thinking of putting back our FileURLConnection impl and add support for directory listing. This looks like the safest option for now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157040#4157040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157040

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: DeploymentScopeBaseName from JAR prepending JNDI Name

by bstansberry＠jboss.com

See also related discussion at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=135477 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157037#4157037 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157037

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Inconsistent usage of the Ejb3Deployment.deploymentScope

by bstansberry＠jboss.com

See also http://www.jboss.com/index.html?module=bb&op=viewtopic&t=135054 for related discussion. Scott's comment on that thread: anonymous wrote : I changed the JBoss5DeploymentScope to use an empty "" base name if the deployment is not an ear, so that should help with legacy expectations for the jndi name. leads me to think the extra data in the ObjectName can be avoided by checking for a null base name. Pretty arcane way to discriminate though. Getting rid of the extra data is a good thing to do, as the ObjectName forms the container's id, which is transmitted as invocation metadata with every remote request. For persistence units with JBC as a 2nd level cache, a similar approach to building a unique name is used in the JBC FQN for the cache region -- which again gets sent over the wire with any cache change messages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157035#4157035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157035

16 years, 3 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Is META-INF in the classpath?

by alesj

"adrian(a)jboss.org" wrote : Bug report: http://jira.jboss.com/jira/browse/JBDEPLOY-47 What would a test for this look like? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157034#4157034 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157034

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: DeploymentScopeBaseName from JAR prepending JNDI Name

by wolfc

This is becoming ugly. A deployment scope was meant to denote a JavaEEApplication (/ EAR) and thus it implements it as such. If the usage has changed we should at least disconnect DeploymentScope from JavaEEApplication. Furthermore the determination of whether there is an EAR or not appears to be broken. As the jboss-seam-dvd application gets deployed with a deployment scope with a null base name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157029#4157029 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157029

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: HDScanner exception

by scott.stark＠jboss.org

I have reproduced it on a new f9 install with the latest sun jdk: | 06:56:05,036 INFO [ServerInfo] Java version: 1.5.0_15,Sun Microsystems Inc. | 06:56:05,045 INFO [ServerInfo] Java VM: Java HotSpot(TM) 64-Bit Server VM 1.5.0_15-b04,Sun Microsystems Inc. | 06:56:05,045 INFO [ServerInfo] OS-System: Linux 2.6.25-14.fc9.x86_64,amd64 | each hd scan is leaking 27 descriptors it seems, and the lsof count for the process just keeps growing. | [starksm@banshee testsuite]$ lsof -p 20881 | wc | 146 1306 19918 | [starksm@banshee testsuite]$ lsof -p 20881 | wc | 128 1142 17046 | [starksm@banshee testsuite]$ lsof -p 20881 | wc | 151 1349 21177 | [starksm@banshee testsuite]$ lsof -p 20881 | wc | 178 1592 25874 | [starksm@banshee testsuite]$ lsof -p 20881 | wc | 205 1835 30571 | ... | [starksm@banshee testsuite]$ lsof -p 20881 | wc | 259 2321 39965 | ... | [starksm@banshee testsuite]$ lsof -p 20881 | wc | 529 4751 86935 | ... | [starksm@banshee testsuite]$ lsof -p 20881 | wc 1042 9368 176178 | I also see the same problem with the open jdk 1.6.0-b09 bundled with f9. I guess http://jira.jboss.com/jira/browse/JBCOMMON-55 should be reopened. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157027#4157027 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157027

16 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2008