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 >>> * >>> <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 >> >> > > > -- > 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 * <http://www.nuwanbando.com/>
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
