Open a JIRA GERONIMO-5009 to track it. 2009/12/31 Ivan <[email protected]>
> > > 2009/12/31 David Jencks <[email protected]> > > >> 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 <[email protected]> >> >>> >>> >>> 2009/12/29 David Jencks <[email protected]> >>> >>> >>>> 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
