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 <[email protected]> wrote: > Hi, > > On Mon, Nov 28, 2011 at 1:08 PM, Sanjiva Weerawarana <[email protected]>wrote: > >> 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 <[email protected]>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 <[email protected]> wrote: >>> >>>> Hi Ruchira, >>>> >>>> On Sun, Nov 27, 2011 at 9:24 AM, Ruchira Wageesha <[email protected]>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 >>>>> [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 >>>> * >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >> email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 >> 650 265 8311 >> blog: http://sanjiva.weerawarana.org/ >> >> >> 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 > * > > -- *Thanks & Regards, Nuwan Bandara Senior Software Engineer WSO2 Inc. | http://wso2.com lean . enterprise . middleware http://nuwan.bandara.co *
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
