it will be deploy twich for this reason :
if a do that java -jar.... -a /temp/multiples/
and it contains
hudson.war and hudson/
I search for all the .war and the folder that contains : /WEB-INF/web.xml
theses 2 matches the list();
so I'll deploy the hudson.war file into a temp folder
after that I,ll go to the 2th item in the list.. and it's the folder.. so
I'll deploy it too.
when it find a war file.. the context will be the war file name.,.. and when
it finds a folder.. the context will be the folder name..
it need to get tracks or what has been deployed.
2009/3/26 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com>
>
>
> Survivant 00 wrote:
>
>>
>>
>> Why would you do that?
>>
>> suppose that I have a folder :
>>
>>
>> webapp/WEB-INF/classes
>> webapp/WEB-INF/lib
>> webapp/WEB-INF/conf...
>>
>> I'll have all my jars in lib.. but I could have my application compiled in
>> classes.. That was the problem.. it didn't find my servlet unless I put it
>> in a jar into the lib folder.
>>
>
> Hum I'm pretty sure your servlet will be loaded if you drop them under
> WEB-INF/classes...at least this is what it is supposed to work.
>
>
>
>>
>>
>>
>>
>> - doesn't support tld so my example here with freemarker and struts
>> won't load because of that.
>>
>>
>> Any idea why it doesn't work.
>>
>>
>> first we don't have a way to declare it in the GWS. after that in your
>> web pages you have to declare it :
>>
>> <%@ taglib uri="/struts-html-el.tld" prefix="html"%>
>>
>> maybe the server try to do a lookup .. there must have something wierd :)
>> never try actually to debug that.. could be fun.
>>
>>
>> - wierd case.. when the file : hudson.war and the folder hudson/ are
>> in the same folder..
>>
>>
>> What is the issue :-)
>>
>>
>> because we are using a temp folder to deploy the application.. it will be
>> deploying 2 applications with the same context..
>>
>
> I see...but why is it deploying twice is what I would like to learn :-)
>
>
>
>>
>>
>> oh ya... when we deploy a war file.. it's deployed in the OS temp
>> folder, maybe we could pass a param to change that.. or a param to
>> force the war to be expanded.. could fix the previous issue.
>>
>>
>> Agree.
>>
>> File issue for each of the above so we can track them and we can get help
>> from the community. Also what do you think about adding support of a
>> ServletAdapter.deploy() method?
>>
>>
>> just not sure how it will works. first we need to find was need to be
>> deploy.. populate the servletAdapter.. and after that do a
>> ServletAdapter.deploy() ? the work is done at this point :)
>> just give us the "pseudo code" and I will understand what you're saying.
>>
>
>
> ServletAdapter s = new ServletAdapter();
> s.populate(path-to-web.xml)
>
> A+
>
> -- Jeanfrancois
>
>
>
>
>
>>
>>
>> 2009/3/26 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com <mailto:
>> Jeanfrancois.Arcand_at_sun.com>>
>>
>> Salut,
>>
>>
>>
>> Survivant 00 wrote:
>>
>> syntax examples :
>>
>> # 1 : Deploy a war
>>
>> java -jar grizzly-servlet-deployer-1.9.11-SNAPSHOT.jar -a
>> c:/temp/hudson.war
>>
>> the param : -p 8080 is optional. 8080 is the default port
>>
>> the context will be the war file. In this example :
>> http://localhost:8080/hudson/ (don't forget to put the
>> trailing / or it won't work... I filled a bug about that)
>>
>> #2 - Deploy a war expanded.
>>
>> java -jar grizzly-servlet-deployer-1.9.11-SNAPSHOT.jar -a
>> c:/temp/hudson
>>
>> that will give the same result as #1
>>
>>
>> #3 Deploy a servlet
>>
>> java -classpath
>> myservlet.jar;.;grizzly-servlet-deployer-1.9.11-SNAPSHOT.jar
>> com.sun.grizzly.http.servlet.deployer.GrizzlyWebServerDeployer
>> -a web.xml
>>
>> the context will be the default "/"
>>
>> http://localhost:8080/
>>
>> but there is a bug here. (need to fix it.. )
>>
>>
>> if I put that in the web.xml
>>
>> <servlet-mapping>
>> <servlet-name>servletA</servlet-name>
>> <url-pattern>/servlet/*</url-pattern>
>> </servlet-mapping>
>>
>> I was expecting : http://localhost:8080/servlet/ but I got a
>> "Resource Not Found" (is it a bug in my deployer or in GWS..)
>>
>>
>> #4 - Deploy multiples war in the same time. This one in tricky.
>> Here what the folders will look like
>>
>> c:/temp/MultipleWarFolder/
>> /freemarker
>> /WEB-INF
>> /classes
>> /lib
>> /templates
>> hudson.war
>> struts2-showcase-2.0.12.war
>>
>> GWSDeployer will check all the folders in the root and if it
>> find one that contains /WEB-INF/web.xml it will consider it as
>> #2 (expanded war)
>> if it find a .war it will do #1 (war file)
>>
>> and the context will the folder name of the war file name.
>>
>> here the syntax for #4.. (yes it's the same as #2)
>>
>> java -jar grizzly-servlet-deployer-1.9.11-SNAPSHOT.jar -a
>> c:/temp/MultipleWarFolder
>>
>>
>>
>>
>> there are some limitations..
>> - we have 1 classloader.. so if you have multiple war that
>> contains the same librairy but a different version, you will
>> have problem.
>>
>>
>> Yes will work on that.
>>
>>
>> - classloader problem : not able to add classes in the classpath
>> (the jars are fine)
>>
>>
>> Why would you do that?
>>
>>
>>
>> - doesn't support tld so my example here with freemarker and
>> struts won't load because of that.
>>
>>
>> Any idea why it doesn't work.
>>
>>
>>
>> - wierd case.. when the file : hudson.war and the folder hudson/
>> are in the same folder..
>>
>>
>> What is the issue :-)
>>
>>
>>
>>
>> oh ya... when we deploy a war file.. it's deployed in the OS
>> temp folder, maybe we could pass a param to change that.. or a
>> param to force the war to be expanded.. could fix the previous
>> issue.
>>
>>
>> Agree.
>>
>> File issue for each of the above so we can track them and we can get
>> help from the community. Also what do you think about adding support
>> of a ServletAdapter.deploy() method?
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>> any comments ?
>>
>> 2009/3/24 Survivant 00 <survivant00_at_gmail.com
>> <mailto:survivant00_at_gmail.com> <mailto:survivant00_at_gmail.com
>> <mailto:survivant00_at_gmail.com>>>
>>
>>
>> ok. I'll let the refactoring to you.
>>
>> I'll start the documentation tonight and put some examples too.
>> 2009/3/24 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com
>> <mailto:Jeanfrancois.Arcand_at_sun.com>
>> <mailto:Jeanfrancois.Arcand_at_sun.com
>> <mailto:Jeanfrancois.Arcand_at_sun.com>>>
>>
>>
>>
>> Survivant 00 wrote:
>>
>> I'll explain all that :)
>>
>> yes you can delete the module :
>> grizzly-servlet-webserver-deployer
>>
>> but what's wierd.. is that I don't see it in the trunk.
>> unless I'm in a branch and I didn't know that
>>
>>
>> No I've moved it under bundles/... last week or the week
>> before.
>> Now I will test the new module and we may want to move it
>> from
>> contribs/ to modules/ for a possible integration with
>> http-servlet. We may want to add a new API on
>> ServletAdapter like:
>>
>> deploy( path-to-war-file )
>>
>> and under the hood will configure (the same as you did).
>> We may
>> also want to add a
>>
>> parse (path-to-xml)
>>
>> ...but not before I've fixed the classloader issue you have
>> raised (at least on my side) :-)
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>> 2009/3/24 Jeanfrancois Arcand
>> <Jeanfrancois.Arcand_at_sun.com <mailto:Jeanfrancois.Arcand_at_sun.com>
>> <mailto:Jeanfrancois.Arcand_at_sun.com
>> <mailto:Jeanfrancois.Arcand_at_sun.com>>
>> <mailto:Jeanfrancois.Arcand_at_sun.com
>> <mailto:Jeanfrancois.Arcand_at_sun.com>
>> <mailto:Jeanfrancois.Arcand_at_sun.com
>> <mailto:Jeanfrancois.Arcand_at_sun.com>>>>
>>
>>
>> Salut,
>>
>>
>> Survivant 00 wrote:
>>
>> I replace ServletDeployer by
>> GrizzlyWebServerDelpoyer.
>> /contrib/grizzly-servlet-deployer
>>
>>
>> This version support webapp 2.2, 2.3, 2.4, 2.5
>> and 3.0
>>
>> you can launch webapps by using this command
>> line :
>> java -jar
>> grizzly-servlet-deployer-xxx.jar -a
>> path/webapp.war
>>
>> I'll add more javadoc this week and bog about
>> this.
>> I need to
>> show all the potential of that thing.
>>
>>
>> This is great! And what is the context-path used by
>> default? The
>> name of the war file? Will test that. Also, do we
>> still
>> need 2
>> modules? I guess we can get rid of the other one
>> (this
>> time I ask :-)).
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>>
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>>>
>>
>> For additional commands, e-mail:
>> dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>
>> <mailto:dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>>
>> <mailto:dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>
>> <mailto:dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>>
>> For additional commands, e-mail:
>> dev-help_at_grizzly.dev.java.net <mailto:
>> dev-help_at_grizzly.dev.java.net>
>> <mailto:dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>