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

[Design of POJO Server] - Re: Missing EAR/WAR Isolation

by scott.stark＠jboss.org

"jason.greene(a)jboss.com" wrote : | Ah I see, I was confused since currently, EARStructure is parsing jboss-app.xml. | | The issue is the lack of a default if there is no jboss-app.xml (or no loader-repository-config). In the past we had a global isolation setting directly on the ear deployer. So I assumed we are keeping that. I take it we are moving away from it? | No, the global setting should be coming in from the AppParsingDeployer as a default. Its just not been ported over. I created this issue for that: http://jira.jboss.com/jira/browse/JBAS-4214 "jason.greene(a)jboss.com" wrote : | Ah I see. Yes, the issue is that the WS deployer has to inspect every war (WS or not) by loading all servlet classes (and related WS classes if it is in fact a WS deployment). If the DeploymentUnit CL is not isolated, there is the possibility of a conflict with multiple deployments. | | That said, fixing EAR isolation will resolve the WS TCK issues, since they separate the client and server side components in individual EARs. | I created this issue for the externalization of the war class loader. http://jira.jboss.com/jira/browse/JBAS-4215 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029487#4029487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029487

19 years

1
0
0 / 0

[Design of POJO Server] - Re: Missing EAR/WAR Isolation

by jason.greene＠jboss.com

anonymous wrote : | On the first port of the war deployer, jbossweb didn't have a mechanism to accept a class loader so it was commented out. It should be creating a scoped class loader by default though, but its probably still an implementation detail of the webcontainer. It does need to be pulled out so its available at the DeploymentUnit level. I assume that is what you are looking for? | Ah I see. Yes, the issue is that the WS deployer has to inspect every war (WS or not) by loading all servlet classes (and related WS classes if it is in fact a WS deployment). If the DeploymentUnit CL is not isolated, there is the possibility of a conflict with multiple deployments. That said, fixing EAR isolation will resolve the WS TCK issues, since they separate the client and server side components in individual EARs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029486#4029486 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029486

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Upgrade to JGroups 2.4.1.SP1

by bstansberry＠jboss.com

Thanks, Clebert. JGroups releases aren't interoperable (i.e. a server running 2.4.1 will have issues clustering with one on 2.4.1.SP1), so I don't know if you want to switch versions in an SP. That's somewhat a policy decision for the Messaging team. IMO the most significant thing in 2.4.1.SP1 for normal usage is the fix for http://jira.jboss.com/jira/browse/JGRP-422. We saw the error message reported on that JIRA pretty frequently during shutdown of an AS instance; I assume messaging users would as well. The effect of the problem is just the ERROR message; the shutdown happens correctly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029481#4029481 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029481

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Upgrade to JGroups 2.4.1.SP1

by clebert.suconic＠jboss.com

Also.... I have tested this new release with our clustering testcases.. everything looks fine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029475#4029475 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029475

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Upgrade to JGroups 2.4.1.SP1

by clebert.suconic＠jboss.com

anonymous wrote : What were the main fixes? (any links?) Duh! :-D ::: anonymous wrote : Bela's released a 2.4.1.SP1 (see http://jira.jboss.com/jira/browse/JGRP?report=com.atlassian.jira.plugin.s... ) that's going in AS 4.2.0. I'd like to move AS trunk to it as well, but the build fails with: My fingers were faster than my eyes :-)... But I keep the question... should I upgrade 1.2.0.SP1 to use this new SP release? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029473#4029473 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029473

19 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Upgrade to JGroups 2.4.1.SP1

by clebert.suconic＠jboss.com

I just added compatibility on repository.jboss.org/jboss/messaging I don't know how it will take to be replicated though. Also... we will release JBossMessaging.1.2.0.SP1 this week... do you think I should upgrade JGroups on this release as well? What were the main fixes? (any links?) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029472#4029472 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029472

19 years

1
0
0 / 0

[Design of POJO Server] - Re: Missing EAR/WAR Isolation

by jason.greene＠jboss.com

"scott.stark(a)jboss.org" wrote : The EARStructure defines what the deployable content is in the ear along with what its classpath is. It does not define scoping. This should be coming from the metadata of the AppParsingDeployer (jboss-app.xml, deployer isolation property) that is passed to the ServiceClassLoaderDeployer which should be creating the scoped ULR. | Ah I see, I was confused since currently, EARStructure is parsing jboss-app.xml. The issue is the lack of a default if there is no jboss-app.xml (or no loader-repository-config). In the past we had a global isolation setting directly on the ear deployer. So I assumed we are keeping that. I take it we are moving away from it? anonymous wrote : I'll have to check if this is wired up correctly. I'm working on the jboss5 testsuite so I'll look at the existing ear isolation tests today. | Great thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029467#4029467 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029467

19 years

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Testsuite broken in 4.2

by anil.saldhana＠jboss.com

This is broken in trunk. Can you please comment out dist setting in build.xml of trunk? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029465#4029465 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029465

19 years

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Updating the server task to detect OutOfMemoryErrors

by ryan.campbell＠jboss.com

(Just saw your second post) If you mean that you need to extend the JUnitTask, I agree; there doesn't seem to be a way to substitute your own TestRunner implementation. Studying JUnitTask and JUnitTestRunner in the Ant source distro are good first steps for this task. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029455#4029455 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029455

19 years

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Updating the server task to detect OutOfMemoryErrors

by ryan.campbell＠jboss.com

Yeah, that's the jist of it. Though as Carlo pointed out, if the server is experiencing an OOME, you won't get a response. So you need some kind of timeout on the call to the server. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029453#4029453 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029453

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