Re: [Carbon-dev] [Architecture] AppDev Deployment Model and Gadget Server Redesign
Hi All, We have completed a POC for this deployment today, the POC is available at [1] as a sample. We have finalized the name as Jaggery for the AppDev project witch poped with most number of votes, hence created the initial set of components at [2] and hostobjects at [3]. At present Gadget Server (trunk) can be taken as an OOTB container for Jaggery Apps, but are planing to have this as a part of App Server as well. Please refer to the sample [1] to have a better understanding on developing and deploying a Jaggery App. We have also created a milestone plan for the framework (table below) [4], and planing to do the first milestone release by 23rd December. Gadget Server will be re-designed based on the Jaggery framework and the portal will be deployed as a Jaggery App, will share the milestone plan for new GS in a separate thread. Regards, /Nuwan [1] https://svn.wso2.org/repos/wso2/trunk/carbon/products/gs/modules/apps/portal/ [2] https://svn.wso2.org/repos/wso2/trunk/carbon/components/jaggery/ [3] https://svn.wso2.org/repos/wso2/trunk/carbon/components/hostobjects/ [4] https://docs.google.com/a/wso2.com/spreadsheet/ccc?key=0Apo8DTpT8DFCdEdWOENjT0hfRTdDa3dxUFhtcmdCa3c Milestone Tasks Tentative dates M1 jaggery-core, jaggery-javascript 23rd Dec Custom deployer (Support only archived types) Hostobjects - registry, file, ws, xhr, rdb, email, app Gadget Tag Documentation / Article / Blog Securing serverside scripts Sample App (JSSP/HTML5 based) M2 Custom deployer (Support for exploded mode) Mid January Permission model Hostobjects - rest of the HOs in MS Caching model Upload/Keep custom HO by tenants On Mon, Nov 28, 2011 at 2:03 PM, Nuwan Bandara nu...@wso2.com wrote: Hi, On Mon, Nov 28, 2011 at 1:08 PM, Sanjiva Weerawarana sanj...@wso2.comwrote: I'm glad you got the webapp-style model to work. Let me summarize to make sure I got it: - person writes a watalappan app called foo (basically by creating a foo/ directory and putting various files including static stuff like html and images in the file hierarchy) Correct. - they zip it up to foo.zip or simply upload the whole directory or just copy it to the right place - upload/copy where? ideally it should be a watalappanapps directory (similar to webapps) under which the foo directory is created +1, right now we are using the same webapp directory, and still working on supporting the exploded mode (where you can copy a foo/ directly) at AS level. - a custom deployer (not the webapp deployer but another one) does the work of making foo into a valid context and doing all the underlying work to make messages coming to /foo to find its way to the right stuff with the right stuff loaded Yes, using this deployer we can add the default servlet mappings etc, to the Watalappan apps. - watalappan deployer should only load each file as its hit .. just like html pages or jsps or php. plus any edit should be detected Its already working in that way. like in PHP even you edit the page and in the next request those changes will be reflected. - gadget rendering comes in by saying something like x:gadget .../ or using the JS library from Shindig (which means the call is coming from the client) +1, similar fashion we support the js tag in jssp, we are having the gadget tag. the tag lib will be added to the AS lib/ dir, so all the web apps can use the tag. - any other carbon stuff we want to expose is also thru either server side JS APIs, custom tags or client side JS APIs +1 UNDER NO CONDITION do we have Java-isms coming thru to the Watalappan developer. +1 Is that all correct? We are planing to bundle up some of these features, as a POC, where you deploy (using the default webapp deployer) a watalappan app in AS (in webapps dir) and have a gadget in one of the JSSPs. Regards, /Nuwan Sanjiva. On Sun, Nov 27, 2011 at 10:43 PM, Ruchira Wageesha ruch...@wso2.comwrote: Hi, I just tried this deployment model locally and worked as expected. Needed hostobject/JSSservlet jars were put into CARBON_HOME/lib or CARBON_HOME/lib/api directories where tomcat looks for classes. This way, all hostobjects were available to any webapp deployed in AS. JS app stuff was packaged as a war and put it to the webapps directory where it was deployed by the existing webapp deployer. As I used directly the Webapp deployer, I had to keep several servlet mappings in the web.xml of the app. But, if we are writing a custom JSS deployer, then we would be able to automatically add those servlet mappings during the deployment. One headache that I had, was to copy all the needed dependencies of appdev stuff into the above lib or api directories although there are still in the plugins directory. I had to do this as tomcat classloader hasn't allowed to search within plugins directory. I even had to keep, axis2 stuff in the lib directory. In the long run, this won't be a
Re: [Carbon-dev] [Architecture] AppDev Deployment Model and Gadget Server Redesign
Hi,
On Mon, Nov 28, 2011 at 1:08 PM, Sanjiva Weerawarana sanj...@wso2.comwrote:
I'm glad you got the webapp-style model to work. Let me summarize to make
sure I got it:
- person writes a watalappan app called foo (basically by creating a foo/
directory and putting various files including static stuff like html and
images in the file hierarchy)
Correct.
- they zip it up to foo.zip or simply upload the whole directory or just
copy it to the right place
- upload/copy where? ideally it should be a watalappanapps directory
(similar to webapps) under which the foo directory is created
+1, right now we are using the same webapp directory, and still working on
supporting the exploded mode (where you can copy a foo/ directly) at AS
level.
- a custom deployer (not the webapp deployer but another one) does the
work of making foo into a valid context and doing all the underlying work
to make messages coming to /foo to find its way to the right stuff with the
right stuff loaded
Yes, using this deployer we can add the default servlet mappings etc, to
the Watalappan apps.
- watalappan deployer should only load each file as its hit .. just like
html pages or jsps or php. plus any edit should be detected
Its already working in that way. like in PHP even you edit the page and in
the next request those changes will be reflected.
- gadget rendering comes in by saying something like x:gadget .../ or
using the JS library from Shindig (which means the call is coming from the
client)
+1, similar fashion we support the js tag in jssp, we are having the
gadget tag. the tag lib will be added to the AS lib/ dir, so all the web
apps can use the tag.
- any other carbon stuff we want to expose is also thru either server side
JS APIs, custom tags or client side JS APIs
+1
UNDER NO CONDITION do we have Java-isms coming thru to the Watalappan
developer.
+1
Is that all correct?
We are planing to bundle up some of these features, as a POC, where you
deploy (using the default webapp deployer) a watalappan app in AS (in
webapps dir) and have a gadget in one of the JSSPs.
Regards,
/Nuwan
Sanjiva.
On Sun, Nov 27, 2011 at 10:43 PM, Ruchira Wageesha ruch...@wso2.comwrote:
Hi,
I just tried this deployment model locally and worked as expected. Needed
hostobject/JSSservlet jars were put into CARBON_HOME/lib or
CARBON_HOME/lib/api directories where tomcat looks for classes. This way,
all hostobjects were available to any webapp deployed in AS. JS app stuff
was packaged as a war and put it to the webapps directory where it was
deployed by the existing webapp deployer.
As I used directly the Webapp deployer, I had to keep several servlet
mappings in the web.xml of the app. But, if we are writing a custom JSS
deployer, then we would be able to automatically add those servlet mappings
during the deployment.
One headache that I had, was to copy all the needed dependencies of
appdev stuff into the above lib or api directories although there are still
in the plugins directory. I had to do this as tomcat classloader hasn't
allowed to search within plugins directory. I even had to keep, axis2 stuff
in the lib directory.
In the long run, this won't be a good solution. So, it would be better to
separate share-able stuff and non-share-able private stuff. Then share-able
stuff will be able to seen by both tomcat classloaders and OSGI
classloaders. But I am not sure whether this will cause other issues??
One other thing is to allow keeping tenant specific hostobjects. So, we
will have to keep hostobjects uploaded by tenant admins and load only when
that tenant's apps are called. Here we can simply switch to a classloader
by whom tenant specific stuff + common hostobjects can be seen.
The last simple question is, where do we keep those tenant specific
hostobjects? Hope GReg/ESB people do the same with registry
extensions/custom mediators etc??
/Ruchira
On Sun, Nov 27, 2011 at 10:28 AM, Nuwan Bandara nu...@wso2.com wrote:
Hi Ruchira,
On Sun, Nov 27, 2011 at 9:24 AM, Ruchira Wageesha ruch...@wso2.comwrote:
But problem comes, when we want to access registry, carboncontext from
a jssapps? Before finding a solution for this, it would be better if
someone clarifies the way we can access registry in an AS's JSP webapp.
Anyway, it should be WS* api of registry? If so, we can ask jss app
developers too the same solution.
I looked in to the webapp code and it seems it allows registry access
via CarbonContext instance. Using that, we can also get the registry for
the registry hostobject(i.e. for jss webapp case). Further, when we put our
hostobjects in CARBON_HOME/lib/hostobjects, then they will be seen by the
classloaders of webapps. Likewise, we can implement the jss webapp
deployment model.
+1 I think this is a good model. So we have the framework inside
{Carbon_Home}/lib and people can write their Watalappan apps, and deploy
in webappd dir.
Re: [Carbon-dev] [Architecture] AppDev Deployment Model and Gadget Server Redesign
Hi,
I just tried this deployment model locally and worked as expected. Needed
hostobject/JSSservlet jars were put into CARBON_HOME/lib or
CARBON_HOME/lib/api directories where tomcat looks for classes. This way,
all hostobjects were available to any webapp deployed in AS. JS app stuff
was packaged as a war and put it to the webapps directory where it was
deployed by the existing webapp deployer.
As I used directly the Webapp deployer, I had to keep several servlet
mappings in the web.xml of the app. But, if we are writing a custom JSS
deployer, then we would be able to automatically add those servlet mappings
during the deployment.
One headache that I had, was to copy all the needed dependencies of appdev
stuff into the above lib or api directories although there are still in the
plugins directory. I had to do this as tomcat classloader hasn't allowed to
search within plugins directory. I even had to keep, axis2 stuff in the lib
directory.
In the long run, this won't be a good solution. So, it would be better to
separate share-able stuff and non-share-able private stuff. Then share-able
stuff will be able to seen by both tomcat classloaders and OSGI
classloaders. But I am not sure whether this will cause other issues??
One other thing is to allow keeping tenant specific hostobjects. So, we
will have to keep hostobjects uploaded by tenant admins and load only when
that tenant's apps are called. Here we can simply switch to a classloader
by whom tenant specific stuff + common hostobjects can be seen.
The last simple question is, where do we keep those tenant specific
hostobjects? Hope GReg/ESB people do the same with registry
extensions/custom mediators etc??
/Ruchira
On Sun, Nov 27, 2011 at 10:28 AM, Nuwan Bandara nu...@wso2.com wrote:
Hi Ruchira,
On Sun, Nov 27, 2011 at 9:24 AM, Ruchira Wageesha ruch...@wso2.comwrote:
But problem comes, when we want to access registry, carboncontext from a
jssapps? Before finding a solution for this, it would be better if someone
clarifies the way we can access registry in an AS's JSP webapp. Anyway, it
should be WS* api of registry? If so, we can ask jss app developers too the
same solution.
I looked in to the webapp code and it seems it allows registry access via
CarbonContext instance. Using that, we can also get the registry for the
registry hostobject(i.e. for jss webapp case). Further, when we put our
hostobjects in CARBON_HOME/lib/hostobjects, then they will be seen by the
classloaders of webapps. Likewise, we can implement the jss webapp
deployment model.
+1 I think this is a good model. So we have the framework inside
{Carbon_Home}/lib and people can write their Watalappan apps, and deploy
in webappd dir.
For this to work seamlessly we need to have the exploded war support in
AppServer. once we get that I guess we can easily deploy JSS and JSSP files
simply by dropping them to the directory, or syncing it via the registry.
The only issue at hand right now is, providing a gadget based dashboard
for products like BAM and GREG. For that I believe carbon:gadget tag will
be a solution. so if a product need multiple dashboards they can write
their own dashboard, taking the base one as a sample.
Regards,
/Nuwan
/Ruchira
___
Architecture mailing list
architect...@wso2.org
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
architect...@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
--
Ruchira Wageesha
Software Engineer - WSO2 Inc. www.wso2.com
Email: ruch...@wso2.com Blog: ruchirawagee...@blogspot.com
Mobile: +94775493444
Lean . Enterprise . Middleware
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Architecture] AppDev Deployment Model and Gadget Server Redesign
I'm glad you got the webapp-style model to work. Let me summarize to make
sure I got it:
- person writes a watalappan app called foo (basically by creating a foo/
directory and putting various files including static stuff like html and
images in the file hierarchy)
- they zip it up to foo.zip or simply upload the whole directory or just
copy it to the right place
- upload/copy where? ideally it should be a watalappanapps directory
(similar to webapps) under which the foo directory is created
- a custom deployer (not the webapp deployer but another one) does the work
of making foo into a valid context and doing all the underlying work to
make messages coming to /foo to find its way to the right stuff with the
right stuff loaded
- watalappan deployer should only load each file as its hit .. just like
html pages or jsps or php. plus any edit should be detected
- gadget rendering comes in by saying something like x:gadget .../ or
using the JS library from Shindig (which means the call is coming from the
client)
- any other carbon stuff we want to expose is also thru either server side
JS APIs, custom tags or client side JS APIs
UNDER NO CONDITION do we have Java-isms coming thru to the Watalappan
developer.
Is that all correct?
Sanjiva.
On Sun, Nov 27, 2011 at 10:43 PM, Ruchira Wageesha ruch...@wso2.com wrote:
Hi,
I just tried this deployment model locally and worked as expected. Needed
hostobject/JSSservlet jars were put into CARBON_HOME/lib or
CARBON_HOME/lib/api directories where tomcat looks for classes. This way,
all hostobjects were available to any webapp deployed in AS. JS app stuff
was packaged as a war and put it to the webapps directory where it was
deployed by the existing webapp deployer.
As I used directly the Webapp deployer, I had to keep several servlet
mappings in the web.xml of the app. But, if we are writing a custom JSS
deployer, then we would be able to automatically add those servlet mappings
during the deployment.
One headache that I had, was to copy all the needed dependencies of appdev
stuff into the above lib or api directories although there are still in the
plugins directory. I had to do this as tomcat classloader hasn't allowed to
search within plugins directory. I even had to keep, axis2 stuff in the lib
directory.
In the long run, this won't be a good solution. So, it would be better to
separate share-able stuff and non-share-able private stuff. Then share-able
stuff will be able to seen by both tomcat classloaders and OSGI
classloaders. But I am not sure whether this will cause other issues??
One other thing is to allow keeping tenant specific hostobjects. So, we
will have to keep hostobjects uploaded by tenant admins and load only when
that tenant's apps are called. Here we can simply switch to a classloader
by whom tenant specific stuff + common hostobjects can be seen.
The last simple question is, where do we keep those tenant specific
hostobjects? Hope GReg/ESB people do the same with registry
extensions/custom mediators etc??
/Ruchira
On Sun, Nov 27, 2011 at 10:28 AM, Nuwan Bandara nu...@wso2.com wrote:
Hi Ruchira,
On Sun, Nov 27, 2011 at 9:24 AM, Ruchira Wageesha ruch...@wso2.comwrote:
But problem comes, when we want to access registry, carboncontext from
a jssapps? Before finding a solution for this, it would be better if
someone clarifies the way we can access registry in an AS's JSP webapp.
Anyway, it should be WS* api of registry? If so, we can ask jss app
developers too the same solution.
I looked in to the webapp code and it seems it allows registry access
via CarbonContext instance. Using that, we can also get the registry for
the registry hostobject(i.e. for jss webapp case). Further, when we put our
hostobjects in CARBON_HOME/lib/hostobjects, then they will be seen by the
classloaders of webapps. Likewise, we can implement the jss webapp
deployment model.
+1 I think this is a good model. So we have the framework inside
{Carbon_Home}/lib and people can write their Watalappan apps, and deploy
in webappd dir.
For this to work seamlessly we need to have the exploded war support in
AppServer. once we get that I guess we can easily deploy JSS and JSSP files
simply by dropping them to the directory, or syncing it via the registry.
The only issue at hand right now is, providing a gadget based dashboard
for products like BAM and GREG. For that I believe carbon:gadget tag will
be a solution. so if a product need multiple dashboards they can write
their own dashboard, taking the base one as a sample.
Regards,
/Nuwan
/Ruchira
___
Architecture mailing list
architect...@wso2.org
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/
Re: [Carbon-dev] [Architecture] AppDev Deployment Model and Gadget Server Redesign
But problem comes, when we want to access registry, carboncontext from a jssapps? Before finding a solution for this, it would be better if someone clarifies the way we can access registry in an AS's JSP webapp. Anyway, it should be WS* api of registry? If so, we can ask jss app developers too the same solution. I looked in to the webapp code and it seems it allows registry access via CarbonContext instance. Using that, we can also get the registry for the registry hostobject(i.e. for jss webapp case). Further, when we put our hostobjects in CARBON_HOME/lib/hostobjects, then they will be seen by the classloaders of webapps. Likewise, we can implement the jss webapp deployment model. /Ruchira ___ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Architecture] AppDev Deployment Model and Gadget Server Redesign
Hi Ruchira,
On Sun, Nov 27, 2011 at 9:24 AM, Ruchira Wageesha ruch...@wso2.com wrote:
But problem comes, when we want to access registry, carboncontext from a
jssapps? Before finding a solution for this, it would be better if someone
clarifies the way we can access registry in an AS's JSP webapp. Anyway, it
should be WS* api of registry? If so, we can ask jss app developers too the
same solution.
I looked in to the webapp code and it seems it allows registry access via
CarbonContext instance. Using that, we can also get the registry for the
registry hostobject(i.e. for jss webapp case). Further, when we put our
hostobjects in CARBON_HOME/lib/hostobjects, then they will be seen by the
classloaders of webapps. Likewise, we can implement the jss webapp
deployment model.
+1 I think this is a good model. So we have the framework inside
{Carbon_Home}/lib and people can write their Watalappan apps, and deploy
in webappd dir.
For this to work seamlessly we need to have the exploded war support in
AppServer. once we get that I guess we can easily deploy JSS and JSSP files
simply by dropping them to the directory, or syncing it via the registry.
The only issue at hand right now is, providing a gadget based dashboard for
products like BAM and GREG. For that I believe carbon:gadget tag will be
a solution. so if a product need multiple dashboards they can write their
own dashboard, taking the base one as a sample.
Regards,
/Nuwan
/Ruchira
___
Architecture mailing list
architect...@wso2.org
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
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Architecture] AppDev Deployment Model and Gadget Server Redesign
As JS apps would act as a replacement for webapps, then it should follow the same model as the current AS's webapp model. i.e. user upload a zip/war which will then put into a jsapps directory in the repository and get deployed programmatically as it does with AS webapps. Further, when we deploy those apps, it seems we can set servlet mappings programatically for those apps. Again, for taglibs, then we would be able to put those jars in tomcats extension/libs/endorsed(I am still reading about tomcat) where tomcat classloader of jsapps will see. So, this would be a good deployment model for jsapps as multitenancy, registry sync can be implemented easily as it does in JSP webapp model. Further, if there are any tenant specific Hostobjects, then we can put them in a way, per jssapp classloaders can see. But problem comes, when we want to access registry, carboncontext from a jssapps? Before finding a solution for this, it would be better if someone clarifies the way we can access registry in an AS's JSP webapp. Anyway, it should be WS* api of registry? If so, we can ask jss app developers too the same solution. Then, when the gadget server's usecase is considered, we again want those frontend stuff to be developed using jss. But if we deploy that webapp following the above procedure, then that won't be a solution for this particular problem. AFAIK, carbon core itself is deployed as a webapp, but it contains only servlet bridge?? Anyway, only for the dashboard usecase, we can deploy that specially on carbon servers tomcat environment, where we would be able to access OSGI stuff?? /Ruchira On Fri, Nov 25, 2011 at 11:13 AM, Nuwan Bandara nu...@wso2.com wrote: 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 ruch...@wso2.comwrote: On Thu, Nov 24, 2011 at 6:42 AM, Nuwan Bandara nu...@wso2.com wrote: Hi Ruchira, Find my thoughts below, On Wed, Nov 23, 2011 at 11:39 PM, Ruchira Wageesha ruch...@wso2.comwrote: 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
Re: [Carbon-dev] [Architecture] AppDev Deployment Model and Gadget Server Redesign
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 ruch...@wso2.com wrote: On Thu, Nov 24, 2011 at 6:42 AM, Nuwan Bandara nu...@wso2.com wrote: Hi Ruchira, Find my thoughts below, On Wed, Nov 23, 2011 at 11:39 PM, Ruchira Wageesha ruch...@wso2.comwrote: 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
Re: [Carbon-dev] [Architecture] AppDev Deployment Model and Gadget Server Redesign
Hi Ruchira, Find my thoughts below, On Wed, Nov 23, 2011 at 11:39 PM, Ruchira Wageesha ruch...@wso2.com 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. 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 ? 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: ruch...@wso2.com Blog: ruchirawagee...@blogspot.com Mobile: +94775493444 Lean . Enterprise . Middleware ___ Architecture mailing list architect...@wso2.org 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 Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
Re: [Carbon-dev] [Architecture] AppDev Deployment Model and Gadget Server Redesign
On Thu, Nov 24, 2011 at 6:42 AM, Nuwan Bandara nu...@wso2.com wrote: Hi Ruchira, Find my thoughts below, On Wed, Nov 23, 2011 at 11:39 PM, Ruchira Wageesha ruch...@wso2.comwrote: 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: ruch...@wso2.com Blog: ruchirawagee...@blogspot.com Mobile: +94775493444 Lean . Enterprise . Middleware ___ Architecture mailing list
