geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: About deploying web applications to Tomcat 7.0
Date Thu, 31 Dec 2009 09:25:33 GMT

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?

> 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 !<moduleName> 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.

> 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.

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,
>    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


Mime
View raw message