Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 28287 invoked from network); 31 Dec 2009 14:10:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 31 Dec 2009 14:10:30 -0000 Received: (qmail 67154 invoked by uid 500); 31 Dec 2009 14:10:29 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 67058 invoked by uid 500); 31 Dec 2009 14:10:29 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 67050 invoked by uid 99); 31 Dec 2009 14:10:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Dec 2009 14:10:29 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of xhhsld@gmail.com designates 209.85.221.201 as permitted sender) Received: from [209.85.221.201] (HELO mail-qy0-f201.google.com) (209.85.221.201) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Dec 2009 14:10:22 +0000 Received: by qyk39 with SMTP id 39so6269405qyk.27 for ; Thu, 31 Dec 2009 06:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=3PLoHSZMibU/g9XghJBANY42/EQmbwMijd0FTxHCdao=; b=bw++pvn5DKpRtIwOf1fvXYR16NU8px8j/r4gtUJ3H81eMeSCE7/TXCKGdbAS/KvnOF AWlmLMOwIg3pxx0S0TkUpvb7RzqXuQI7P8R5KfGMCvMoD5IJSb1dyfRnTWgFE134dFT7 o07/NNx5ipSzFMvVgoIOGernVnDfXrKIs6p6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=v2jjQnttlesJQ5CTN/tYDoikoT9X5PGLRR5i4L4eOO8FhF+11UIXC5wF0lKhvL5OOr +01OeUXNi2BnBsytFRxqQfmZGWV7VGT9nzTMykOLVs0y+cQUHi7IQAG6vndf29R3SwtF ErX6PEKNBFzOjEDukAIDQ0jg+9U6yzBX9WVls= MIME-Version: 1.0 Received: by 10.229.20.206 with SMTP id g14mr2944360qcb.32.1262268601277; Thu, 31 Dec 2009 06:10:01 -0800 (PST) In-Reply-To: <9990A76C-D2B4-41D4-B6DA-10C0D0A272C0@yahoo.com> References: <45f744e40912280651p3898657i1a980ef996db5a1e@mail.gmail.com> <45f744e40912281829o64d7ae30g6e007e36291a3261@mail.gmail.com> <45f744e40912310033o7d1ef43au151cb3e8d183973a@mail.gmail.com> <9990A76C-D2B4-41D4-B6DA-10C0D0A272C0@yahoo.com> Date: Thu, 31 Dec 2009 22:10:01 +0800 Message-ID: <45f744e40912310610m675d251cta9647ae1b7304193@mail.gmail.com> Subject: Re: About deploying web applications to Tomcat 7.0 From: Ivan To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary=0016e64bd5bc971d9a047c06cfbe --0016e64bd5bc971d9a047c06cfbe Content-Type: text/plain; charset=ISO-8859-1 2009/12/31 David Jencks > > On Dec 31, 2009, at 12:33 AM, Ivan wrote: > > > After updating some deplyment codes, currently, I could deploy a simple web > application to geronimo-tomcat server. As discussed in the past, a packed > car file will installed in the repository folder finally, not an exploded > one. Currently, a temp folder is created for each DeploymentContext, and the > application files would be extracted there for analysis, then it will be > packed as a single jar file. However, there are still some detailed things > need to be discussed, e.g. for the efficiency consideration, I write the > plugin meta data eariler, in the DeploymentContext.getConfigurationData, > while it was in the RepositoryConfigurationStore.install in the past, as I > found that it is not easy to modify an existed jar file. > > > I don't understand what you are proposing here, could you be more explicit? > Just list the issues while enabling the war deployment, have you also begun the code changes for it ? If not, I would like to open a JIRA, and try to work on it. > Anyway, at least, it means that it is feasible to keep a packed file in the > repository. > Later, I will try to deploy an EAR package contains more than one WARs. > > > This works fine now for me in the base console with the limitation that all > modules in the ear get into the same single bundle. > > I will try the solution about dividing the ear as multiple bundles, the ear > itself is one, all the modules it contains are the others, and it is > possible to use require-bundle to connect the module bundle to the ear > bundle. > > > I'd prefer to avoid require-bundle. I was thinking of modifying the pax > url handler so that we could continue to repackage the ear as we do now, but > have the car file contain several bundles corresponding to the different > modules inside. We could perhaps imitate jar urls and append ! > to point to an "internal" bundle. If we did this the car would still be a > single artifact in maven but would supply all the bundles at once. > Yes, require-bundle did not have a good reputation in the OSGI world, but in this scenario, I think we could use it to reduce the complexity. Keeping the same package way is a good choice, for currently, the repository directory is a really 'repository', Geronimo never loads any class from it, ^_^. But if in that way, the file is not a standard bundle, and it only works for the special url handler. > > One thing I am thinking is that how to generate the exports for the ear > bundle, maybe the deployer might need use something like asm to scan all the > library files. > > > I think we should look into using BND for this. > Yes, BND should help us. > > thanks > david jencks > > > Any comment ? > > 2009/12/29 Ivan > >> >> >> 2009/12/29 David Jencks >> >> >>> On Dec 28, 2009, at 6:51 AM, Ivan wrote: >>> >>> Hi, >>>> With the latest welcome-tomcat-server assembly, I could run the >>>> pre-shipped welcome plugins, and everything seems well, with pre-compiled >>>> and non-pre-compiled jsps. >>>> Later, I tried to deploy a simple web application via deploy command, >>>> it failed as expected ;-) >>>> The current problem I think we need to solve first is that we should >>>> have a decision about how to store the package in the repository. From the >>>> usual work style in OSGI, it is better to keep a packed file there. About >>>> the inplace way, so far I could not see any way to deploy a folder to the >>>> OSGI runtime. Currently, all the copying work is done by the implementations >>>> of ResourceContext, each modulebuilder would be resposible for copying the >>>> module files to the folder in the repository. An intuitive way is to provide >>>> a new implementation for the ResourceContext, it would support to update the >>>> packed file. >>>> Any comment before I try it ? I did not go through all the deployment >>>> codes, something might be missed. ^_^ >>>> >>> >>> I don't think we can support in-place deployment until after we figure >>> out how to support direct use of bundles in our maven-like repo without >>> copying them into the osgi structure. I think about this sometimes but >>> don't regard it as a high priority. >>> >> >> I agree, for supporting in-place deployment, I guess that we might need >> to extend mvn protocol handler or even Felix runtime. >> Actually, I also checked the Karaf, as it said that it supports to deploy >> a folder to the OSGI runtime. But it just packed the folder to a jar file, >> then process the deployment, which it is not acceptable in my opinion. >> >> >> >>> Can you be more specific about what doesn't work, and how you tried to >>> deploy? I didn't know any of the deploy commands worked enough to even >>> start deployment. If they do, It's not obvious to me what might be broken. >>> Does a packed bundle get created? Does geroimo know how to tell osgi about >>> it? >>> >>> The command that I use is : deploy deploy sample.war. The exception that >> I got is that >> ---> >> Unable to cache bundle: mvn:default/TestWeb2/1.0/car >> error in opening zip file >> >> at >> org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(CommandDistribute.java:168) >> at >> org.apache.geronimo.deployment.cli.CommandDistribute.execute(CommandDistribute.java:124) >> at >> org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:166) >> at org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64) >> at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:109) >> at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65) >> at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) >> <--- >> >> This exception was thrown by Felix while starting the deployed bundle in >> ConfigurationManager, which means TomcatBuilder had successfully configure >> the web application. Although I am not sure the ConfigurationBuilder >> behaviored correctly, the deployment process passed. >> >> As I said in the last email, from the current trend I saw, we kept a >> packed car file in the repository while building the server, so in the >> deployment process, we might need to keep consistent, which means for each >> modulebuilder, it does not need to copy those files in the module >> installation, the only thing they need to do is just to update some files in >> the packed file if required. >> >> >>> thanks >>> david jencks >>> >>> >>> -- >>>> Ivan >>>> >>> >>> >> >> >> -- >> thanks >> Ivan >> > > > > -- > Ivan > > > -- Ivan --0016e64bd5bc971d9a047c06cfbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/12/31 David Jencks <david_jencks@yahoo.com&= gt;

On De= c 31, 2009, at 12:33 AM, Ivan wrote:

After updating some deplyment codes, currently, I could deploy a simple we= b application to geronimo-tomcat server. As discussed in the past, a packed= car file will installed in the repository folder finally, not an exploded = one. Currently, a temp folder is created for each DeploymentContext, and th= e application files would be extracted there for analysis, then it will be = packed as a single jar file. However, there are still some detailed things = need to be discussed, e.g. for the efficiency consideration, I write the pl= ugin meta data eariler, in the DeploymentContext.getConfigurationData, whil= e it was in the RepositoryConfigurationStore.install in the past, as I foun= d that it is not easy to modify an existed jar file.

I don't understand what you are propo= sing here, could you be more explicit?

=A0= Just list the issues while enabling the war deployment, have you also begun= the code changes for it ? If not, I would like to open a JIRA, and try to = work on it.


Anyway, at least, it means that it is feasible to keep a packed file in th= e repository.
Later, I will try to deploy an EAR package contains more = than one WARs.=A0

This works fine now= for me in the base console with the limitation that all modules in the ear= get into the same single bundle.

I will try the solution ab= out dividing the ear as multiple bundles, the ear itself is one, all the mo= dules it contains are the others, and it is possible to use require-bundle = to connect the module bundle to the ear bundle.

I'd prefer to avoid require-bundle. =A0I was = thinking of modifying the pax url handler so that we could continue to repa= ckage the ear as we do now, but have the car file contain several bundles c= orresponding to the different modules inside. =A0We could perhaps imitate j= ar urls and append !<moduleName> to point to an "internal" = bundle. =A0If we did this the car would still be a single artifact in maven= but would supply all the bundles at once.

=A0 =A0 Yes, require-bundle did not have = a good reputation in the OSGI world, but in this scenario, I think we could= use it to reduce the complexity.
=A0=A0=A0 Keeping the same package way= is a good choice, for currently, the repository directory is a really '= ;repository', Geronimo never loads any class from it, ^_^.=A0 But if in= that way, the file is not a standard bundle, and it only works for the spe= cial url handler.

One thing I am thinking is that how to generate the exports for the = ear bundle, maybe the deployer might need use something like asm to scan al= l the library files.

I think we should look into using BND for= this.
=A0
=A0 =A0 Yes, BND should help us= .

thanks
= david jencks

Any comment ?

2009/12/29 Ivan <xhhsld@gmail.com>


2009/12/29 David Jencks <david_jencks@yahoo.com>


On Dec 28, 2009, at 6:51 AM, Ivan wrote:

Hi,
=A0 =A0With the latest welcome-tomcat-server assembly, I could run= the pre-shipped welcome plugins, and everything seems well, with pre-compi= led and non-pre-compiled jsps.
=A0 =A0Later, I tried to deploy a simple= web application via deploy command, it failed as expected ;-)
=A0 =A0The current problem I think we need to solve first is that we shoul= d have a decision about how to store the package in the repository. From th= e usual work style in OSGI, it is better to keep a packed file there. About= the inplace way, so far I could not see any way to deploy a folder to the = OSGI runtime. Currently, all the copying work is done by the implementation= s of ResourceContext, each modulebuilder would be resposible for copying th= e module files to the folder in the repository. An intuitive way is to prov= ide a new implementation for the ResourceContext, it would support to updat= e the packed file.
=A0 =A0Any comment before I try it ? I did not go through all the deploym= ent codes, something might be missed. ^_^

I don't think we can support in-place deployment until after we figur= e out how to support direct use of bundles in our maven-like repo without c= opying them into the osgi structure. =A0I think about this sometimes but do= n't regard it as a high priority.
=A0The command that I use is : deploy deploy s= ample.war. The exception that I got is that=A0
--->
Unable to cac= he bundle: mvn:default/TestWeb2/1.0/car
error in opening zip file
at org.apache.geronimo.deployment.cli.CommandDistribute.executeOnline(Comm= andDistribute.java:168)
at org.apache.geronimo.deployment.cli.CommandDi= stribute.execute(CommandDistribute.java:124)
at org.apache.geronimo.depl= oyment.cli.DeployTool.execute(DeployTool.java:166)
at org.apache.geronimo.system.main.MainBridge.execute(MainBridge.java:64) at org.apache.geronimo.main.Bootstrapper.execute(Bootstrapper.java:109)<= br>at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:65)<= br> at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) <---

This exception was thrown by Felix while starting the dep= loyed bundle in ConfigurationManager, which means TomcatBuilder had success= fully configure the web application. Although I am not sure the Configurati= onBuilder behaviored correctly, the deployment process passed.

As I said in the last email, from the current trend I saw, we kept a p= acked car file in the repository while building the server, so in the deplo= yment process, we might need to keep consistent, which means for each modul= ebuilder, it does not need to copy those files in the module installation, = the only thing they need to do is just to update some files in the packed f= ile if required.
=A0
th= anks
david jencks


--
Ivan




--
thanks
Ivan



--
Ivan




--
Ivan
--0016e64bd5bc971d9a047c06cfbe--