Hi Manu, The real requirement is accessing the configuration from Tomcat valve level or at the listener which is triggering at the deployment time. Hence both JavaEE and Jaggery apps needs to adhere to the same standards. What you proposed to make the OAuth capable app as a first class citizen is just one usecase whereas we have certificate based, basic oauth, JWT token based etc. These all types of apps needs to understand these configurations. In that case the feasible solution is to get the context parameters since it can be accessible from core level no matter what the app type is.
Regards, Dilshan On Mon, Sep 14, 2015 at 1:14 PM, Manuranga Perera <[email protected]> wrote: > I know this is only a few lines of code chance and it's very feasible to > do this. But this will introduce yet another way of configuring a jaggery > app, it's bad to have too many ways of doing the same thing. This confuses > users (programmer) even more. > Eg: should we put admin user name in store.json or in jaggery.conf ? > > The solution addresses your use case, but messes everyone else's. Looking > from a Jaggery platform point of view, I think the proper way to do this is > to introduce OAuth capable apps as a first class citizen in jaggery world. > So in jaggery.conf you can introduce a config section to say if it's OAuth > enable and other OAuth related info such as token endpoint. Since you have > done all the necessary Java coding, adding this as a native jaggery feature > is only few steps away, and I warmly welcome you to contribute to jaggery > code. > > > On Mon, Sep 14, 2015 at 12:47 PM, Manuranga Perera <[email protected]> wrote: > >> >> >> On Mon, Sep 14, 2015 at 12:12 PM, Manuranga Perera <[email protected]> wrote: >> >>> Hi Harshan/Prabath, >>> >>> For all jaggery apps so far, we have kept different applications >>> specific configuration files. This is a different model than keeping all >>> the config in WEB.XML in j2ee world. Each way has its own merits, but >>> consistency is more important than implementation. If are switching to the >>> other model we have to do it consistently across the platform, not just >>> implement a feature just for this use case. >>> >>> On Mon, Sep 14, 2015 at 11:58 AM, Harshan Liyanage <[email protected]> >>> wrote: >>> >>>> Hi Manoj, >>>> >>>> It is already reading & setting some properties defined in jaggery.conf >>>> file to servlet-context. But it is not using the context-parameters defined >>>> in jaggery.conf. Thats what we are proposing here. If you can check the >>>> *JaggeryConfListener >>>> *class defined in [1] line 286, it only expecting some default >>>> parameters defined in jaggery.conf. >>>> >>>> [1]. >>>> https://github.com/wso2/jaggery/blob/8c58180f541f110609b9c0c66cc3e0c62c8caa39/components/jaggery-core/org.jaggeryjs.jaggery.app.mgt/src/main/java/org/jaggeryjs/jaggery/app/mgt/TomcatJaggeryWebappsDeployer.java >>>> >>>> Thanks, >>>> >>>> Harshan Liyanage >>>> Software Engineer >>>> Mobile: *+94724423048* >>>> Email: [email protected] >>>> Blog : http://harshanliyanage.blogspot.com/ >>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>> lean.enterprise.middleware. >>>> >>>> On Mon, Sep 14, 2015 at 11:41 AM, Manoj Gunawardena <[email protected]> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> In the TomcatJaggeryWebappsDeployer.java class has a method called >>>>> readJaggeryConfig (Line 378). When looking at the code it seems to read >>>>> jaggery.conf file and read settings in to a json string. In the line >>>>> 214 , that settings send to the addWebapp method. Is this not read >>>>> jaggery.conf >>>>> file. Please correct me if I am wrong. >>>>> >>>>> Thanks >>>>> >>>>> >>>>> On Mon, Sep 14, 2015 at 10:35 AM, Prabath Abeysekera < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Sep 11, 2015 at 3:33 PM, Harshan Liyanage <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> adding @architecture. >>>>>>> >>>>>>> Harshan Liyanage >>>>>>> Software Engineer >>>>>>> Mobile: *+94724423048* >>>>>>> Email: [email protected] >>>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>>>> lean.enterprise.middleware. >>>>>>> >>>>>>> On Fri, Sep 11, 2015 at 3:26 PM, Harshan Liyanage <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> We have a requirement to read some configuration parameters when a >>>>>>>> web-app gets deployed to initiate the dynamic-client authentication >>>>>>>> process. We have both JAVA webapps and jaggery webapps. Currently I'm >>>>>>>> using >>>>>>>> a LifecycleListener and reading the required context-params using the >>>>>>>> ServletContext. This approach works well for JAVA webapps. >>>>>>>> >>>>>>>> But this method can not be used for jaggery webapps as the existing >>>>>>>> implementation of TomcatJaggeryWebappsDeployer [1] does not support >>>>>>>> defining and using the context-parameters in jaggery-conf file (it only >>>>>>>> supports *displayName* and *logLevel *parameters). However as the >>>>>>>> jaggery.conf file is designed to serve the same purpose as the web.xml >>>>>>>> file >>>>>>>> of a web-app, I think its necessary to have the context-parameter >>>>>>>> support >>>>>>>> in jaggery.conf file. >>>>>>>> >>>>>>>> Is it ok to have context-params defined in jaggery.conf file or are >>>>>>>> there any better solution for this issue? Please share your opinions. >>>>>>>> >>>>>>> >>>>>> IMO, what's proposed is what needs to be done. In other words, each >>>>>> webapp, irrespective of the fact that it is a regular webapp or jaggery >>>>>> app, has to have a descriptor of some sort, which is used to configure >>>>>> the >>>>>> runtime behaviour of it. If the deployment behaviour of a jaggery app is >>>>>> something like, reading all configs from its own jaggery.conf and putting >>>>>> them into a runtime representation of a web.xml, then rather than going >>>>>> for >>>>>> any non-standard configuration file, etc, I believe, the same config can >>>>>> be >>>>>> used to implement certain application specific context parameters as >>>>>> well. >>>>>> Therefore, +1 for the proposed functionality. >>>>>> >>>>>> Appreciate some feedback from the rest of the community as well. >>>>>> >>>>>> Cheers, >>>>>> Prabath >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> [1]. >>>>>>>> https://github.com/wso2/jaggery/blob/8c58180f541f110609b9c0c66cc3e0c62c8caa39/components/jaggery-core/org.jaggeryjs.jaggery.app.mgt/src/main/java/org/jaggeryjs/jaggery/app/mgt/TomcatJaggeryWebappsDeployer.java >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Harshan Liyanage >>>>>>>> Software Engineer >>>>>>>> Mobile: *+94724423048* >>>>>>>> Email: [email protected] >>>>>>>> Blog : http://harshanliyanage.blogspot.com/ >>>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>>>>> lean.enterprise.middleware. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Prabath Abeysekara >>>>>> Technical Lead >>>>>> WSO2 Inc. >>>>>> Email: [email protected] >>>>>> Mobile: +94774171471 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Manoj Gunawardena >>>>> Tech Lead >>>>> WSO2, Inc.: http://wso2.com >>>>> lean.enterprise.middleware >>>>> Mobile : +94 77 2291643 >>>>> >>>> >>>> >>> >>> >>> -- >>> With regards, >>> *Manu*ranga Perera. >>> >>> phone : 071 7 70 20 50 >>> mail : [email protected] >>> >> >> >> >> -- >> With regards, >> *Manu*ranga Perera. >> >> phone : 071 7 70 20 50 >> mail : [email protected] >> > > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : [email protected] > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dilshan Edirisuriya Senior Software Engineer - WSO2 Mob: + 94 777878905 http://wso2.com/ https://www.linkedin.com/profile/view?id=50486426
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
