Re: About deploying web applications to Tomcat 7.0

[Ivan <xh...@gmail.com>]

Open a JIRA GERONIMO-5009 to track it.

2009/12/31 Ivan <xh...@gmail.com>

>
>
> 2009/12/31 David Jencks <da...@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 <xh...@gmail.com>
>>
>>>
>>>
>>> 2009/12/29 David Jencks <da...@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
>



-- 
Ivan

Re: About deploying web applications to Tomcat 7.0

[Ivan <xh...@gmail.com>]

By the way, is there any introduction for the Aries application bundle ? I
did not find too much things on their wiki.

2010/1/4 Ivan <xh...@gmail.com>

> Yes, I am also sure that it should be easy to make the mvn protocol handler
> to support the nested bundle function.  The reason for saying "not a
> standard bundle" is for the no-copying OSGI bundle deployment, I guess that
> it might be more difficult if the source file is a nested bundle file.
> However, it is just a guess ;-)
>
> 2010/1/4 David Jencks <da...@yahoo.com>
>
>
>> On Jan 3, 2010, at 5:53 PM, Ivan wrote:
>> <snip>
>>
>>  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.
>>>
>>
>> Well, after the bundle gets extracted by the url handler it's a plain
>> ordinary bundle.  The car-with bundles-inside is really just a delivery
>> mechanism.  I'm pretty sure it would be easy to implement, but might not be
>> a great idea long term.  It might be convenient until we find something
>> better.  On the other hand it might get popular in other contexts.
>>
>> I forgot to mention that the other approach that seems promising to me is
>> to use the application bundle idea from the aries project.
>>
>> thanks
>> david jencks
>>
>>
>>>  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
>>>
>> <snip>
>>
>
>
>
> --
> Ivan
>



-- 
Ivan

Re: About deploying web applications to Tomcat 7.0

[Ivan <xh...@gmail.com>]

Yes, I am also sure that it should be easy to make the mvn protocol handler
to support the nested bundle function.  The reason for saying "not a
standard bundle" is for the no-copying OSGI bundle deployment, I guess that
it might be more difficult if the source file is a nested bundle file.
However, it is just a guess ;-)

2010/1/4 David Jencks <da...@yahoo.com>

>
> On Jan 3, 2010, at 5:53 PM, Ivan wrote:
> <snip>
>
>  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.
>>
>
> Well, after the bundle gets extracted by the url handler it's a plain
> ordinary bundle.  The car-with bundles-inside is really just a delivery
> mechanism.  I'm pretty sure it would be easy to implement, but might not be
> a great idea long term.  It might be convenient until we find something
> better.  On the other hand it might get popular in other contexts.
>
> I forgot to mention that the other approach that seems promising to me is
> to use the application bundle idea from the aries project.
>
> thanks
> david jencks
>
>
>>  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
>>
> <snip>
>



-- 
Ivan

Re: About deploying web applications to Tomcat 7.0

[David Jencks <da...@yahoo.com>]

On Jan 3, 2010, at 5:53 PM, Ivan wrote:
<snip>
>> 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.

Well, after the bundle gets extracted by the url handler it's a plain  
ordinary bundle.  The car-with bundles-inside is really just a  
delivery mechanism.  I'm pretty sure it would be easy to implement,  
but might not be a great idea long term.  It might be convenient until  
we find something better.  On the other hand it might get popular in  
other contexts.

I forgot to mention that the other approach that seems promising to me  
is to use the application bundle idea from the aries project.

thanks
david jencks
>
>> 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
<snip>