> Bundle-SymbolicName, Bundle-Version, Bundle-ManifestVersion,
> Import-Package, Web-ContextPath.
OK, In addition, I want to know whether export-Package should be support
or not?
> Agreed. If you can help securing the telnet port, then that would be
> awesome.
I am considering a design way and tomorrow want to discuss with you.
> That's what I mean by deployment team has to provide necessary support
> for not assuming that the input payload is a file. I suggest we support
> #1 to begin with and then wait till deployment team accept a URI argument.
OK!
--Best Regard!
--Tang
Sahoo wrote:
> On Tuesday 10 July 2012 08:25 PM, Tang Yong wrote:
>> Dear Sahoo, Hong, Tom
>>
>>> The war to wab conversion is configurable. So, please evaluate how
>>> user can provide additional configuration.
>> About the above point, after investigating some frameworks with similar
>> functions, I have some ideas to discuss with you.
>>
>> 1. way of war to wab conversion
>>
>> 1) admin cli
>> using "deploy --type=osgi --properties XXX" command, and XXX can be the
>> following:
>>
>> ・Web-ContextPath
>> ・Bundle-SymbolicName
>> ・Bundle-Version
>> ・Bundle-ClassPath
> Well, they can be whatever the uri scheme supports. wab uri scheme
> supports the following:
> Bundle-SymbolicName, Bundle-Version, Bundle-ManifestVersion,
> Import-Package, Web-ContextPath.
>> 2) admin gui
>> I wish to deploy wab the same as using admin cli, thus will more
>> convenient for a user. So, maybe need to extend the current
>> deploy-related gui pages.
> Yes, but let's first get the CLI right.
>> 3) felix shell
>> Although user can telent to felix shell, just as saying on
>> GLASSFISH-16998 and GLASSFISH-13006, maybe turn off the shell for
>> production. So, the way is not a good way.
>>
> Agreed. If you can help securing the telnet port, then that would be
> awesome.
>> 2 protocol of war to wab conversion
>>
>> For a user, he/she maybe deploy a wab using the following protocol:
>>
>> 1)Local File
>> For example: asadmin deploy --type=osgi --properties
>> Web-ContextPath=/test_sample1 e:\test_sample1.war
>>
>> 2)http protocol
>> For example: asadmin deploy ...
>> http://repo1.maven.org/maven2/org/apache/wicket/wicket-examples/1.3.0/wicket-examples-1.3.0.war
>>
>> 3)mvn protocol
>> For example: asadmin deploy ...
>> mvn:org.apache.wicket/wicket-examples/1.3.0/war
>>
>> 4)using a instructions file(Normally a bnd file) to deploy a war using
>> user-defined metadata.
>> For example: asadmin deploy ...
>> E:/Data/Examples/wicket-examples-1.4.7.bnd
>>
>> The above 2),3),4) are all implemented by Pax Web and some other
>> frameworks using pax web(such as Karaf, Paremus Service Fabric,...), so,
>> I think that whether glassfish can also support some of these protocols
>> or not.
>>
> We ca support #1. For the rest, deploy command has to accept a URI as a
> parameter and that's where admin team as well as deployment team have to
> agree. All of the above protocol handlers will work just fine in
> GlassFish when installed in it. I use them in my test framework mvn
> protocol extensively.
>> In addition, if supporting some of 2),3),4), a small problem may be
>> considered. On executed method of DeployCommand class, there are some
>> codes as following:
>>
>> if (!path.exists()) {
>> ...
>> return;
>> }
>> if (!path.canRead()) {
>> ...
>> return;
>> }
>>
> That's what I mean by deployment team has to provide necessary support
> for not assuming that the input payload is a file. I suggest we support
> #1 to begin with and then wait till deployment team accept a URI argument.
>
> Alternatively, we could expose our own command inside osgi-container
> which will use org.glassfish.embeddable.Deployer.deploy(). This method
> already accepts URI as an argument.
>
> Thanks,
> Sahoo
>
>