Hi All,
I have done a small POC on this, took some hits from Sameera as well
(Thanks !).
Ruchira is correct, its quite impossible to deploy this "watalappan" app as
a web app, and refer any resources/servlets/taglibs defined in the Carbon
context (or vise versa). The two environments are completely isolated, and
even if I register a servlet for /foo/*.jss in carbon context and if my
watalappan app is deployed as a webapp in /foo, and if I request
/foo/helloWorld.jss, the requests wont hit the servlet which I initialized
using an OSGI bundle.
Instead I followed a deferent path for deployment. in OSGI there is a way
to install a bundle in exploded form (we even now use this not knowingly
when doing UI changes).
So what I did was,
1. Wrote an initializer bundle, which is meant to init the framework,
1. I initialize shindig here
2. Initialize AppDev framework (Register Servlets/Taglibs etc)
3. I initialize an exploded bundle in the file system (which will act
as the deployment directory)
- Bundle bnd =
bc.installBundle("reference:file:/home/nuwanbando/wso2/builds/wso2as-4.1.1/web");
bnd.start();
- Directory "Web" is an exploded osgi bundle.
- Initially this directory will only have an activator and a
META-INF
- Inside this directory we can put any type of files
4. So from the users point we can simply provide a UI where they can
create/upload JSS/JSSP/HTML (or even JSP) files to this
location. and those
added files will be rendered correctly.
5. Importantly they dont need to know anything about OSGI bundles
etc, they can simply put files like they put PHP scripts in HTTPD
6. In this way, we have full carbon context support (with the Carbon
session)
I do have a working POC on this methodology (Still testing for more
usecases though), Is this a viable deployment pattern for us, for
"Watalappan" apps ?
Regards,
/Nuwan
On Thu, Nov 24, 2011 at 10:36 AM, Ruchira Wageesha <[email protected]> wrote:
>
>
> On Thu, Nov 24, 2011 at 6:42 AM, Nuwan Bandara <[email protected]> wrote:
>
>> Hi Ruchira,
>>
>> Find my thoughts below,
>>
>> On Wed, Nov 23, 2011 at 11:39 PM, Ruchira Wageesha <[email protected]>wrote:
>>
>>> Hi All,
>>>
>>> Most appropriate deployment model of an appdev webapp would be deploying
>>> like a normal webapp which we deploy in AS.
>>>
>>
>> +1, webapp like model is good, but does it have to be bundled up like a
>> war ?. Its better not to. So we can have a model like you write the server
>> side page using JSSP or JSS, and simply drop it to the deployment
>> directory, like we do for PHP scripts in httpd. This will be the best
>> mechanism to realize new GS architecture.
>>
>>
>>> In the appdev framework, we have a set of HostObject(Java classes
>>> written following a convention), Servlets and tags which build the
>>> needed environment for the deployment of JS apps. But there are several
>>> problems with getting this done.
>>>
>>>
>>> 1. We need to keep all the hostobjects, servlets, servlet mappings
>>> and tags in tomcat environment where apps get deployed. How do we achieve
>>> this? I am not familiar with current webapp deployment model. Any
>>> guidelines??
>>> - At the moment in a JS webapp, everything is packed into a war
>>> (hostobjects + servlets + servlet mapings + tags) and deployed in
>>> tomcat.
>>>
>>> We do a similar thing for shindig at present. Shindig has a bunch of
>> servlets, and some guice modules. we are initializing them through a carbon
>> component (gadget.initializer). So anybody want to use gadgets can simply
>> have it by installing the initializer feature.
>>
>> Can we do the same. we packup the appdev framework stuff. which is
>> taglibs, servlets and hostobjects to a AppDev.initializer component. So a
>> person or a product which needs appdev stuff can install this feature, so
>> they can use the defined tags easily.
>>
>
> With the initial goal of JS app framework, an JS app should follow the
> same deployment model as in current carbon webapps. A user should be able
> to write a whole webapp using JS and deploy it in appserver.
>
> AFAIK, tomcat environment of those webapps and tomcat environment of
> carbon server are different and isolated. i.e. tags we have defined in
> carbon server aren't available to webapps and vise versa. So, what I want
> is, I want to make available those taglibs in the tomcat environment of
> webapps. Again, it should be available for any JSS webapp in that
> environment.
>
> Further, the servlet and taglibs classes in webapp tomcat env. need to
> access Hostobject classes which then access registry. So, is it possible to
> access OSGI registry service as those environments are isolated?
>
>>
>>>
>>> 1. For hostobjects like Registry which allows registry calls, how do
>>> we access the registry? Will we have to use WS* api or is there are way
>>> to
>>> access OSGI service/or Java methods from the tags/hostobjects.
>>>
>>> Its better to have a registry hostobject in this case, rather than
>> calling the registry remote API via WSRequest. Cant we have the same
>> registry hostobject we using in MS ? It there a limitation on that ?
>>
>
> In the current registry hostobject of MS, we are using registry OSGI
> service. As it is in carbon server's tomcat, then we have the access to the
> registry OSGI service. But when we are moving to the webapp env., is there
> is a way to access registry from there?
>
>>
>>
>>>
>>> 1. Further, if we are developing the new Gadget frontend as a JS
>>> webapp, then we need to have access to the carbon context and get things
>>> like
>>> - Logged in user
>>> - Tenant ID
>>> - Admin cookie
>>> - backserver url / transport information etc.
>>>
>>>
>> I am not sure about the question, but however, during our discussion,
>> what we wanted to really have is the ability to access carboncontext
>> information from JSSPs and JSSes. If we are to develop the same GS views in
>> AppDev framework, we need to have those propertise in AppDev environment
>> too.
>>
>> I believe we can already obtain the HttpSession from JSS, so I guess some
>> information like logedin user is already available.
>>
>>
>>>
>>> 1. According to the requirements of above [3], then the usage of JS
>>> webapp model in gadget server would be the replacement of current carbon
>>> frontend with JS webapps??
>>>
>>> JS webapp model should be an easy way of creating views rather than
>> creating carbon ui bundles packing them and deploying. Also if we are to
>> deploy these apps like webapps, that means these new UI parts are not
>> installable via P2, or can they ? am not sure about it.
>>
>> But however it is, IMO we need to provide the base, which is the
>> gadget-initializer and the AppDev-initializer instalable via p2, so a user
>> who download vanila Carbon can install these two features and start writing
>> Apps.
>>
>> Regards,
>> /Nuwan
>>
>>
>>> Any suggestions?
>>>
>>> /Ruchira
>>>
>>> --
>>> Ruchira Wageesha
>>> Software Engineer - WSO2 Inc. www.wso2.com
>>>
>>> Email: [email protected] Blog: [email protected]
>>> Mobile: +94775493444
>>>
>>> Lean . Enterprise . Middleware
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Thanks & Regards,
>>
>> Nuwan Bandara
>> Senior Software Engineer
>> WSO2 Inc. | http://wso2.com
>> lean . enterprise . middleware
>>
>> http://nuwan.bandara.co
>> *
>> <http://www.nuwanbando.com/>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Ruchira Wageesha
> Software Engineer - WSO2 Inc. www.wso2.com
>
> Email: [email protected] Blog: [email protected]
> Mobile: +94775493444
>
> Lean . Enterprise . Middleware
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
*Thanks & Regards,
Nuwan Bandara
Senior Software Engineer
WSO2 Inc. | http://wso2.com
lean . enterprise . middleware
http://nuwan.bandara.co
*
<http://www.nuwanbando.com/>
_______________________________________________
Carbon-dev mailing list
[email protected]
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
