You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Ivan <xh...@gmail.com> on 2009/12/28 15:51:14 UTC
About deploying web applications to Tomcat 7.0
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. ^_^
--
Ivan
Re: About deploying web applications to Tomcat 7.0
Posted by 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
Posted by 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
Posted by 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>
Re: About deploying web applications to Tomcat 7.0
Posted by 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
Posted by 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
Re: About deploying web applications to Tomcat 7.0
Posted by 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?
> 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 <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
Re: About deploying web applications to Tomcat 7.0
Posted by Ivan <xh...@gmail.com>.
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.
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. 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. 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.
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
Re: About deploying web applications to Tomcat 7.0
Posted by 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
Re: About deploying web applications to Tomcat 7.0
Posted by 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.
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?
thanks
david jencks
> --
> Ivan