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

[Design of POJO Server] - Re: VFS and JBossAS initialization

by adrian＠jboss.org

Why isn't this just based on the isCachable() attribute? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186690#4186690 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186690

17 years, 5 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: SAR Deployment Deployers Ordering

by adrian＠jboss.org

So now for the reset. Which of the following mistakes is true? :-) "adrian(a)jboss.org" wrote : | 1) The webapp (metadata) you are creating is missing a dependency | so the services are being constructed in the wrong order. | | 2) You are trying to create or access the service in the deployer processing which | you should not be doing. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186680#4186680 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186680

17 years, 5 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: SAR Deployment Deployers Ordering

by adrian＠jboss.org

I'm going to reset this conversation in the next post, but first let me try to summarise the description of this problem from this long thread and explain what I think is really happening (and tell you how you would do exactly what you are asking for although it is the wrong way to do it). So you can tell me where I have misunderstood .... :-) You have a sar that contains a war, e.g. like the web-console | [ejort@warjort management]$ ls -l console-mgr.sar/ | total 1560 | -rw-rw-r-- 1 ejort ejort 142692 Nov 3 20:59 console-mgr-classes.jar | -rw-rw-r-- 1 ejort ejort 307601 Nov 3 20:59 jcommon.jar | -rw-rw-r-- 1 ejort ejort 1098048 Nov 3 20:59 jfreechart.jar | drwxrwxr-x 2 ejort ejort 4096 Nov 3 20:59 META-INF | drwxrwxr-x 7 ejort ejort 4096 Nov 3 21:00 web-console.war | This **naively** means that the webapp in web-console.war needs to be "deployed" after jbossweb.sar But if you look at the logging you'll find this isn't what happens in the deployer layer. This actually hasn't changed in this basic characteristic between jboss4 and jboss5 Since management/console-mgr.sar (the top level deployment name) is before jbossweb.sar it will go through the deployers first (including all its subdeployments). ASIDE: What has changed in JBoss5 is that the deployers are now done in stages so you can be sure the classloader for jbossweb.sar is available in the REAL stage for all other deployments in deploy. This makes NoClassDefFoundErrors due to deployment ordering less likely in JBoss5 even when you don't use the new classloading dependencies. So why isn't this an issue? The answer is that the deployers don't create the webapp. What they do create is metadata on how to construct the webapp and what its dependencies are. i.e. the REAL webapp deployer creates some MBean metadata that says it depends on the main jboss.web service (Tomcat) This dependency makes sure that even though the metadata for web-console.war was created first, the webapp is not constructed until after the webserver is running. Now what I think is really happening for you and why I think you're seeing a problem is that you have one of two problems: 1) The webapp (metadata) you are creating is missing a dependency so the services are being constructed in the wrong order. 2) You are trying to create or access the service in the deployer processing which you should not be doing. Finally (and this is not recommended although Ales hinted at in a kind of hacky way) you can actually make a (sub-)deployment depend on a service. i.e. deployments can have dependencies even at the deployer stage The reason this exists is to do classloading dependencies since the later REAL deployers need to examine classes to create metadata and also need to redeploy applications (reexamine classes) when dependent classes change. So if you really want to (not recommended) make your war subdeployment run after jbossweb The only way to do this currently is programmatically, i.e. you do DeploymentUnit.getDependencyInfo().addIDependOn(...) where the DependencyItem would say that this deployment cannot move to the REAL stage until the jboss.web MBean reaches the INSTALLED stage. NOTE: Since deployments as processed as "all or nothing" through the stages this would actually mean your whole sar doesn't reach the REAL stage until jboss.web is INSTALLED View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186679#4186679 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186679

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

by trustin

"trustin" wrote : 2) HTTP allows multiple parameters with the same key. Therefore, the parameters should be represented as Set<String, List> instead of Map<String, String>. (Same with the issue 1) This issue should go away if we are going to remove the parameter accessor methods. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186674#4186674 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186674

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

by trustin

Hi Andy, Sorry for the late response. I was busy moving to a new house. :) First off, you have done a fantastic job! I'd like to know if there was any difficulty in implementing HTTP on top of Netty so that I can make the Netty API more user-friendly. :) Now, some subtle points: 1) IIUC, HTTP allows multiple headers with the same key. It seems like the current HttpMessage interface assumes there's only one value per key. Therefore, the headers should be represented as Set<String, List> instead of Map<String, String>. This issue will lead to various changes in the header accessor methods of the HttpMessage interface. 2) HTTP allows multiple parameters with the same key. Therefore, the parameters should be represented as Set<String, List> instead of Map<String, String>. (Same with the issue 1) 3) I'm not sure if a multi-line header is decoded correctly: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 4) Reason (error message) is missing in HttpResponse. HttpResponseStatusCode already has the pre-defined reason phrases, but it should be customizable on a per-response basis. (Perhaps we could simply make the HttpResponseStatusCode constructor public?) 5) What about renaming HttpProtocol to HttpVersion? P of HTTP already stands for 'protocol'. Also, HttpRequest.get/setProtocol() needs to be renamed to get/setVersion() or get/setProtocolVersion(). 6) java.net.URI already has a query property. I think we don't need the parameter accessor methods in the HttpRequest interface. We could provide a helper class like UriBuilder later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186673#4186673 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186673

17 years, 5 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: SAR Deployment Deployers Ordering

by alesj

"richard.opalka(a)jboss.com" wrote : "alesj" wrote : | | http://java.dzone.com/articles/a-look-inside-jboss-microconta | I'm reading it now ;) I doubt it will help with the problem above, but it cannot hurt. :-) Perhaps you can use DeploymentUnit::getResourceClassLoader while the _real_ ClassLoader is not yet resolved? But make sure this usage is legit, not actually a hack while doing deployers in a wrong way. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186665#4186665 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186665

17 years, 5 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: SAR Deployment Deployers Ordering

by richard.opalka＠jboss.com

"alesj" wrote : | http://java.dzone.com/articles/a-look-inside-jboss-microconta I'm reading it now ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186662#4186662 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186662

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty exception in Hudson run

by trustin

as advised, please upgrade to Netty 3.0.0.GA. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186660#4186660 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186660

17 years, 5 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: SAR Deployment Deployers Ordering

by richard.opalka＠jboss.com

After short investigation deployers (not deployment) is my real problem. I noticed that .sar archives are deployed first (thus deployers operate on them first too). Deployers are executed first and then archives are scheduled for deployment. My problem is that the .sar archive can incorporate nested EJB or Web deployments representing Web Service deployments. Thus our deployers operate on these nested archives present in .sar archives. Our real problem is that our WebServices deployer depends on JBossWebMetaData ctx classloader which is null in time frame of executing the deployers chain for all .sar archives being processed by deployers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186658#4186658 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186658

17 years, 5 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: SAR Deployment Deployers Ordering

by alesj

"richard.opalka(a)jboss.com" wrote : "alesj" wrote : | | What do you have in your .sar? MBeans? | | | No, just web archive (incorporating WebService endpoints our deployers operate with) | Try with renaming first, and/or do some investigation around jboss-classloading.xml, on how you can declare dependency on module / jar: - https://jira.jboss.org/jira/browse/JBCL-10 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186657#4186657 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4186657

17 years, 5 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 November 2008