geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: About deploying web applications to Tomcat 7.0
Date Thu, 31 Dec 2009 14:10:01 GMT
2009/12/31 David Jencks <david_jencks@yahoo.com>

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

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


-- 
Ivan

Mime
View raw message