[Architecture] Jaggery Configuration file schema
Sanjiva Weerawarana
sanjiva at wso2.com
Wed Mar 14 21:59:10 PDT 2012
Cool :) .. +1 for jaggery.conf BTW (a bit late!).
Sanjiva.
On Wed, Mar 14, 2012 at 6:55 PM, Nuwan Bandara <nuwan at wso2.com> wrote:
> Hi All,
>
> I managed to get the Tomcat issue sorted with some changes to
> ServerManager code in carbon core. So now with jaggery.conf file you con
> configure BASIC auth, error pages etc.
>
> Regards,
> /Nuwan
>
> On Wed, Mar 14, 2012 at 11:14 AM, Chintana Wilamuna <chintana at wso2.com>wrote:
>
>> Understood.
>>
>> Thanks.
>>
>> -Chintana
>>
>>
>> On Wed, Mar 14, 2012 at 11:08 AM, Nuwan Bandara <nuwan at wso2.com> wrote:
>>
>>> Hi Chintana,
>>>
>>> On Wed, Mar 14, 2012 at 10:54 AM, Chintana Wilamuna <chintana at wso2.com>wrote:
>>>
>>>> Hi Nuwan,
>>>>
>>>> This having a config file per application still feels like something we
>>>> inherit from the Java world. If you take a look at a typical PHP
>>>> application, there's no need to have a config file. Of course you can have
>>>> whatever file with which ever format YOU decide but the language itself
>>>> doesn't mandate that.
>>>>
>>>> Having to specify what error pages and so forth on the config file also
>>>> feels weird. Not something a PHP or a JS dev for that matter would usually
>>>> do.
>>>>
>>>> Why cannot we have just a bunch of files? Semantics of this set, which
>>>> page throws out error and how they're thrown, which page defines the login
>>>> form etc... is upto the application writer. IMHO what we should do is
>>>> render the index.{jss,html,jsp} and rest is upto the developer to decide.
>>>>
>>>
>>> I understand ur concern, I also started as a PHP dev way back :)
>>>
>>> Important to mention is that this config file is *not* mandatory, if
>>> you are comfortable with handling all cases you are welcome to do so.
>>>
>>> IMO, Java world has its own good things too :) and with jaggery
>>> I believe we try to bring together good stuff of both worlds. Also, when
>>> you are doing a PHP app, we rely alot on the HTTPD server. for instance,
>>> basic auth, restricting directories etc are done straightaway from the
>>> httpd.conf or a .htaccess file, so even in PHP world there is a notion of a
>>> configuration file. sometimes its globally one file, but you can have ur
>>> own application specific .htaccess file
>>>
>>> so jaggery.json :) is also the same, it's optional, and you can
>>> leverage certain benefits in using it. but if ur a hard core scripting guy,
>>> you can forget about it too.
>>>
>>> Regards,
>>> /Nuwan
>>>
>>>
>>>>
>>>> -Chintana
>>>>
>>>>
>>>> On Wed, Mar 14, 2012 at 10:16 AM, Nuwan Bandara <nuwan at wso2.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Or since we are using JSON, we can straight away say jaggery.json.
>>>>> also +1 for jaggery.conf
>>>>>
>>>>> However I am hit with an implementation blocker, where we cannot add
>>>>> some of the configuration options after the app is deployed by Tomcat. I
>>>>> have talked about this with Azeez. Have to dig deep into tomcat internals
>>>>> to see how we can over come this. i.e I couldnt set the BASIC auth to work,
>>>>> via the tomcat context object. (the way we are registering the default
>>>>> servlets {i.e JSSServlet}). Anyhow will update the thread with my progress.
>>>>>
>>>>> So shall we confirm with the format of the conf file. IMO, the JSON
>>>>> structure would be fine. I did not directly converted the web.xml
>>>>> terminology, I referred to httpd.conf, . htaccess and php.ini
>>>>>
>>>>> Regards,
>>>>> /Nuwan
>>>>>
>>>>>
>>>>> On Wed, Mar 14, 2012 at 4:27 AM, Samisa Abeysinghe <samisa at wso2.com>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 13, 2012 at 3:34 PM, Nuwan Bandara <nuwan at wso2.com>wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> As the conclusion, we will have the relavent web xml params
>>>>>>> represented in a JSON structure something as following,
>>>>>>>
>>>>>>> {
>>>>>>> "errorPages":[
>>>>>>> {
>>>>>>> "error-code":"500",
>>>>>>> "location":"/spring/error?error=500"
>>>>>>> },
>>>>>>> {
>>>>>>> "error-code":"404",
>>>>>>> "location":"/spring/error?error=404"
>>>>>>> }
>>>>>>> ],
>>>>>>> "loginConfig":{
>>>>>>> "authMethod":"FORM",
>>>>>>> "form-login-config":{
>>>>>>> "form-login-page":"/login.jsp",
>>>>>>> "form-error-page":"/fail_login.html"
>>>>>>> }
>>>>>>> },
>>>>>>> "securityConstraints":[
>>>>>>> {
>>>>>>> "securityConstraint":{
>>>>>>> "webResourceCollection":{
>>>>>>> "webResourceName":"foo",
>>>>>>> "urlPattern":"/foo/*"
>>>>>>> },
>>>>>>> "auth-constraint":{ "roleName":"role1" }
>>>>>>> }
>>>>>>> },
>>>>>>> {
>>>>>>> "securityConstraint":{
>>>>>>> "webResourceCollection":{
>>>>>>> "webResourceName":"bar",
>>>>>>> "urlPattern":"/bar/*"
>>>>>>> },
>>>>>>> "auth-constraint":{ "roleName":"role1" }
>>>>>>> }
>>>>>>> }
>>>>>>> ],
>>>>>>> "securityRoles":[
>>>>>>> {
>>>>>>> "securityRole":{ "roleName":"role1" }
>>>>>>> },
>>>>>>> {
>>>>>>> "securityRole":{ "roleName":"role2" }
>>>>>>> }
>>>>>>> ]
>>>>>>> };
>>>>>>>
>>>>>>> In above structure, we have only taken into account the relavent
>>>>>>> parts of the web.xml. namely,
>>>>>>>
>>>>>>> 1. Specificity error pages (404, 500 etc)
>>>>>>> 2. Specificity Auth type (Basic/Form)
>>>>>>> 3. Restricting URL patterns
>>>>>>> 4. User roles (bound to carbon)
>>>>>>>
>>>>>>> For now these are the only configurations we will be reading while
>>>>>>> Jaggery app deployment. Further I was thinking to expose this configuration
>>>>>>> as a json object to the Jaggery app developer. So they can add any
>>>>>>> parameter they want, into the conf file and read it from the application.
>>>>>>> (Like init params in webapps)
>>>>>>>
>>>>>>> Further, the config file will be named as .jaggery
>>>>>>>
>>>>>>
>>>>>> So you got to use ls -a to see that? I am not sure that is right.
>>>>>> Also, we need to think about Windows users. What was the rationale
>>>>>> for .filename?
>>>>>> Why not use conf.jaggery? or jaggery.conf? Latter is more readable
>>>>>> (Jaggery conf for this WebApp)
>>>>>>
>>>>>>>
>>>>>>> So a sample Jaggery application will look like,
>>>>>>>
>>>>>>> ├── foo
>>>>>>> ├── images
>>>>>>> ├── hello.jss
>>>>>>> ├── index.html
>>>>>>> └── *.jaggery*
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> /Nuwan
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 13, 2012 at 4:26 AM, Sanjiva Weerawarana <
>>>>>>> sanjiva at wso2.com> wrote:
>>>>>>>
>>>>>>>> I think we need to think about JS people .. they are used to JSON
>>>>>>>> already. In fact even for us having it in JSON means we can simply read it
>>>>>>>> into a Javascript object and then process (yes implement the logic in
>>>>>>>> Jaggery). So while Java folks will not find it as compelling i think we
>>>>>>>> should go with JSON.
>>>>>>>>
>>>>>>>> Also, when bringing stuff from web.xml we need to be careful to
>>>>>>>> bring the pure Web parts of it and no Java bits of it.
>>>>>>>>
>>>>>>>> Sanjiva.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 12, 2012 at 9:39 AM, Srinath Perera <srinath at wso2.com>wrote:
>>>>>>>>
>>>>>>>>> I also do not like the json format written as text much
>>>>>>>>>
>>>>>>>>> one option is
>>>>>>>>>
>>>>>>>>> errorPage.errorCode=404
>>>>>>>>>
>>>>>>>>> Kind of a approach, basically to put "." to create the tree. It is
>>>>>>>>> bit verbose as users need to list the full path.
>>>>>>>>>
>>>>>>>>> --Srinath
>>>>>>>>>
>>>>>>>>> On Wed, Mar 7, 2012 at 12:45 AM, Samisa Abeysinghe <
>>>>>>>>> samisa at wso2.com> wrote:
>>>>>>>>> > I think the key here is to think about usability. What is the
>>>>>>>>> most usable
>>>>>>>>> > for scripting folks?
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Tue, Mar 6, 2012 at 9:00 PM, Nuwan Bandara <nuwan at wso2.com>
>>>>>>>>> wrote:
>>>>>>>>> >>
>>>>>>>>> >> Hi Samisa,
>>>>>>>>> >>
>>>>>>>>> >> So if we take "contextParam" as a key there are multiple values
>>>>>>>>> for this,
>>>>>>>>> >> each value is again a key-value pair, so we end up in a json
>>>>>>>>> structure. Same
>>>>>>>>> >> goes with other elements in a webapp. If not we will have to
>>>>>>>>> invent a new
>>>>>>>>> >> configuration syntax (simple key-values), and then we have to
>>>>>>>>> write a
>>>>>>>>> >> mapping logic to convert them to web.xml equivalent.
>>>>>>>>> >>
>>>>>>>>> >> Regards,
>>>>>>>>> >> /Nuwan
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> On Tue, Mar 6, 2012 at 7:25 PM, Samisa Abeysinghe <
>>>>>>>>> samisa at wso2.com> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>> Why cannot we use just key-value properties in here? That is
>>>>>>>>> much more
>>>>>>>>> >>> simple compared to XML.
>>>>>>>>> >>>
>>>>>>>>> >>> On Tue, Mar 6, 2012 at 7:04 PM, Nuwan Bandara <nuwan at wso2.com>
>>>>>>>>> wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>> Hi All,
>>>>>>>>> >>>>
>>>>>>>>> >>>> At present we do not have a configuration file specific to
>>>>>>>>> Jaggery, As
>>>>>>>>> >>>> an alternative, you can add a web.xml in to WEB-INF directory
>>>>>>>>> (This is
>>>>>>>>> >>>> not mandatory), However for certain cases developers need a
>>>>>>>>> Hidden directory
>>>>>>>>> >>>> to keep configuration options.
>>>>>>>>> >>>>
>>>>>>>>> >>>> We are thinking of reserving {JAGGERY_APP_DIR}/conf for this
>>>>>>>>> purpose,
>>>>>>>>> >>>> and have a configuration file called jaggery.json(.xml ?) to
>>>>>>>>> hold the
>>>>>>>>> >>>> configuration options. We have already mapped the web.xml to
>>>>>>>>> a json
>>>>>>>>> >>>> structure, but IMO, its not easily understandable like an XML
>>>>>>>>> format, so was
>>>>>>>>> >>>> wondering if we should go with the same web.xml schema, the
>>>>>>>>> json structure
>>>>>>>>> >>>> is as follows (one-to-one mapping with web.xml schema).
>>>>>>>>> >>>>
>>>>>>>>> >>>> {
>>>>>>>>> >>>> "contextParam":[
>>>>>>>>> >>>> {"name1":"value1"},
>>>>>>>>> >>>> {"name2":"value2"}
>>>>>>>>> >>>> ],
>>>>>>>>> >>>> "errorPage":[
>>>>>>>>> >>>> {"errorCode":"404", "location":"\/error.jss"}
>>>>>>>>> >>>> ],
>>>>>>>>> >>>> "loginConfig":{
>>>>>>>>> >>>> "authMethod":"FORM", "realmName":"Example Form-Based
>>>>>>>>> >>>> Authentication Area",
>>>>>>>>> >>>> "formLoginConfig":{
>>>>>>>>> >>>>
>>>>>>>>> "formLoginPage":"\/security\/protected\/login.jsp",
>>>>>>>>> >>>> "formError-page":"\/security\/protected\/error.jsp"
>>>>>>>>> >>>> }
>>>>>>>>> >>>> },
>>>>>>>>> >>>> "securityConstraint":{
>>>>>>>>> >>>> "displayName":"Example Security Constraint",
>>>>>>>>> >>>> "webResourceCollection":{
>>>>>>>>> >>>> "webResourceName":"Protected Area",
>>>>>>>>> >>>> "urlPattern":"\/security\/protected\/*",
>>>>>>>>> >>>> "httpMethod":["DELETE", "GET", "POST", "PUT"]
>>>>>>>>> >>>> },
>>>>>>>>> >>>> "authConstraint":{
>>>>>>>>> >>>> "roleName":["tomcat", "role1"]
>>>>>>>>> >>>> }
>>>>>>>>> >>>> },
>>>>>>>>> >>>> "securityRole":[
>>>>>>>>> >>>> {"roleName":"role1"},
>>>>>>>>> >>>> {"roleName":"role2"}
>>>>>>>>> >>>> ]
>>>>>>>>> >>>> }
>>>>>>>>> >>>>
>>>>>>>>> >>>> IMHO, we do not have to remove all the Java Web Application
>>>>>>>>> features
>>>>>>>>> >>>> when doing Jaggery, if there is something good to be adopted,
>>>>>>>>> we should
>>>>>>>>> >>>> certainly use it. I feel, the XML schema is much more
>>>>>>>>> suitable for
>>>>>>>>> >>>> configuration rather than asking users to understand (and
>>>>>>>>> use) a json
>>>>>>>>> >>>> structure.
>>>>>>>>> >>>>
>>>>>>>>> >>>> WDYT ?
>>>>>>>>> >>>>
>>>>>>>>> >>>> --
>>>>>>>>> >>>> Thanks & Regards,
>>>>>>>>> >>>>
>>>>>>>>> >>>> Nuwan Bandara
>>>>>>>>> >>>> Senior Software Engineer
>>>>>>>>> >>>> WSO2 Inc. | http://wso2.com
>>>>>>>>> >>>> lean . enterprise . middleware
>>>>>>>>> >>>>
>>>>>>>>> >>>> http://nuwan.bandara.co
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> _______________________________________________
>>>>>>>>> >>>> Architecture mailing list
>>>>>>>>> >>>> Architecture at wso2.org
>>>>>>>>> >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>> >>>>
>>>>>>>>> >>> Thanks,
>>>>>>>>> >>> Samisa...
>>>>>>>>> >>>
>>>>>>>>> >>> Samisa Abeysinghe
>>>>>>>>> >>> VP Engineering
>>>>>>>>> >>> WSO2 Inc.
>>>>>>>>> >>> http://wso2.com
>>>>>>>>> >>> http://wso2.org
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> _______________________________________________
>>>>>>>>> >>> Architecture mailing list
>>>>>>>>> >>> Architecture at 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
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> _______________________________________________
>>>>>>>>> >> Architecture mailing list
>>>>>>>>> >> Architecture at wso2.org
>>>>>>>>> >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>> >>
>>>>>>>>> > Thanks,
>>>>>>>>> > Samisa...
>>>>>>>>> >
>>>>>>>>> > Samisa Abeysinghe
>>>>>>>>> > VP Engineering
>>>>>>>>> > WSO2 Inc.
>>>>>>>>> > http://wso2.com
>>>>>>>>> > http://wso2.org
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > _______________________________________________
>>>>>>>>> > Architecture mailing list
>>>>>>>>> > Architecture at wso2.org
>>>>>>>>> > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ============================
>>>>>>>>> Srinath Perera, Ph.D.
>>>>>>>>> http://www.cs.indiana.edu/~hperera/
>>>>>>>>> http://srinathsview.blogspot.com/
>>>>>>>>> _______________________________________________
>>>>>>>>> Architecture mailing list
>>>>>>>>> Architecture at wso2.org
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sanjiva Weerawarana, Ph.D.
>>>>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
>>>>>>>> email: sanjiva at wso2.com; 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
>>>>>>>> Architecture at 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
>>>>>>> Architecture at wso2.org
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>> Thanks,
>>>>>> Samisa...
>>>>>>
>>>>>> Samisa Abeysinghe
>>>>>> VP Engineering
>>>>>> WSO2 Inc.
>>>>>> http://wso2.com
>>>>>> http://wso2.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> Architecture at 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
>>>>> Architecture at wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Chintana Wilamuna
>>>> Associate Technical Lead
>>>> WSO2, Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> phone: +94 75 211 1106
>>>> blog: http://engwar.com/
>>>> photos: http://flickr.com/photos/chintana
>>>> linkedin: http://www.linkedin.com/in/engwar
>>>> twitter: twitter.com/std_err
>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> Architecture at 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
>>> Architecture at wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Chintana Wilamuna
>> Associate Technical Lead
>> WSO2, Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> phone: +94 75 211 1106
>> blog: http://engwar.com/
>> photos: http://flickr.com/photos/chintana
>> linkedin: http://www.linkedin.com/in/engwar
>> twitter: twitter.com/std_err
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture at 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
> Architecture at wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
email: sanjiva at wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
650 265 8311
blog: http://sanjiva.weerawarana.org/
Lean . Enterprise . Middleware
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.wso2.org/pipermail/architecture/attachments/20120315/906f4d8c/attachment-0001.html>
More information about the Architecture
mailing list