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