Hi,
You might want to look at httpservice implementation.
Class OSGiMainAdapter manages all registrations, delegates keeping track of
what has been registered to OSGiCleanMapper (not so clean anymore).
You would probably need to take it to next level, so WarAdapter would take
care of contexts been
deployed. But still you might find this code handy.
HTH,
Hubert.
On Thu, Mar 26, 2009 at 6:08 PM, Survivant 00 <survivant00_at_gmail.com> wrote:
> 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
>>
>>
>