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.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/>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
650 265 8311
blog: http://sanjiva.weerawarana.org/
Lean . Enterprise . Middleware
_______________________________________________
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
