Re: [Architecture] Customizing OAuth access token value by an extension

2013-12-16 Thread Prabath Siriwardena
+1 Please create an issue in Redmine.. Thanks & regards, -Prabath On Tue, Dec 17, 2013 at 12:29 PM, Asela Pathberiya wrote: > Hi All, > > AFAIK, OAuth token value can be an any string and there is no special > format has been defined. Therefore I guess, It is better to create an > extension

Re: [Architecture] Customizing OAuth access token value by an extension

2013-12-16 Thread Johann Nallathamby
Hi Asela, It's a funny coincidence that me and you are thinking of the same thing at the same time. I was also thinking about this change for the next release in the morning. Basically our access token issuance is done by the grant handlers. Therefore to modify access token issuing we need to wri

[Architecture] Customizing OAuth access token value by an extension

2013-12-16 Thread Asela Pathberiya
Hi All, AFAIK, OAuth token value can be an any string and there is no special format has been defined. Therefore I guess, It is better to create an extension to build the access token. Currently, It seems to be that OAuth implementation have not an simple extension to customize the returning acce

Re: [Architecture] [C5] Logging framework

2013-12-16 Thread Chamil Jeewantha
Hi Sameera, What are the benefits of having logging function as an OSGI service, Can't we simply make logging available in the plain java way across all the bundles? Chamil On Mon, Dec 16, 2013 at 12:02 PM, Sameera Jayasoma wrote: > We've implemented the logging functionality in C5 is using

Re: [Architecture] Connector:LinkedIn

2013-12-16 Thread Malaka Silva
Hi Indika, Method companyLookUp should be companyLookup. If we use getProfileFields without Field Selectors what happens? Will it return all available fields or just ID? Best Regards, Malaka On Fri, Dec 13, 2013 at 6:16 PM, indika prasad wrote: > *Introduction* > > LinkedIn, application crea

Re: [Architecture] Fwd: [AppFactory] We should have a XSD to the appfactory configuration file.

2013-12-16 Thread Harsha Thirimanna
Yes , +1 to clear and make it proper way. My concern, if there is a XSD and using some Jaxb generated objects to read and validate config, then it is very easy to find and change the code when we change config file every time because jaxb gives compilation error when validation is failed after we

Re: [Architecture] Fwd: [AppFactory] We should have a XSD to the appfactory configuration file.

2013-12-16 Thread Janaka Ranabahu
Hi Harsha, I would not like to take this as an immediate action item that we must do. IMO, we should give more priority to cleaning up the Appfactory.xml and making it simpler and cleaner as possible. That is when we can focus on the XSD to validate the config. WDYT? Thanks, Janaka On Mon, Dec

Re: [Architecture] [AppFactory] We should have a XSD to the appfactory configuration file.

2013-12-16 Thread Harsha Thirimanna
even though we didn't have xsd validation, we had proper custom validator against this config file when we read it. :) . But my concern was , there should be a XSD to this config file now. Rapidly changing mean, we had to change it several time completely. Because of that we didn't try to create

Re: [Architecture] [AppFactory] We should have a XSD to the appfactory configuration file.

2013-12-16 Thread Eranda Sooriyabandara
Hi Harsha, It's not about the rapidly changing, but It is how we should handle errors. Without this validation we should be written bunch of unnecessary error handling codes. AFAIU, this should be added in the design phase and evolved in implementation. Anyway let's add it up. Thanks Eranda On S