Hi Sumedha, Lakmali, +1 for the fix. However, small suggestion to make the endpoint optional, if somebody wanted to automatically register G-Reg's resource API in a remote AM instance or if they have a proxy/LB in front of G-Reg. Lakmali, I'm assuming that this is possible, if not, that's an interesting feature too.
Thanks, Senaka. On Mon, Aug 5, 2013 at 7:10 AM, Sumedha Rubasinghe <sume...@wso2.com> wrote: > > > On Sun, Aug 4, 2013 at 6:21 PM, Lakmali Baminiwatta <lakm...@wso2.com>wrote: > >> Hi, >> >> For adding the API while server startup, new configuration has added to >> the api-manager.xml. By enabling this configuration in Greg, new API will >> be added to the Publisher in CREATED state. >> >> <StartupAPIPublisher> >> >> <!--Define many API elements as below to publish many APIs --> >> <API> >> <Context>/resource</Context> >> <Provider>admin</Provider> >> <Endpoint>http://localhost:9763/resource</Endpoint> >> > > Lakmali, > This endpoint needs to be computed & should adhere port offset. We are > exposing an API in running server, thus specifying like this is not > necessary. > > > >> <Version>1.0.0</Version> >> </API> >> >> </StartupAPIPublisher> >> >> For the External APIM case, above configuration can be configured in the >> external API Manager instance. >> >> Thanks, >> Lakmali >> >> >> On 26 July 2013 10:45, Lakmali Baminiwatta <lakm...@wso2.com> wrote: >> >>> Hi all, >>> >>> >>> On 26 July 2013 06:25, Vijitha Kumara <viji...@wso2.com> wrote: >>> >>>> Please update the status on this as we need to finalize the work for >>>> the release. Note what is supported for this release and what's pending >>>> etc... >>>> >>>> >>>> I was working on publishing the API at the server startup by calling >>> the Publisher API. So for that API Publisher app should be available. I >>> wrote a ServerStartupHandler implementation whose invoke() method is >>> activated once the server has started. But when the process hits this >>> invoke() method, login to the publisher-app/mgt-console is failing. These >>> issues are discussed in *'[DEV]OSGI bundles startup order'. * >>> >>> So proceding with this, we have two other alternative approaches, >>> >>> 1. Go for a new Admin page where the Product's internal APIs are listed >>> and and administrative user has the option of creating/publishing them. >>> 2. When the API mgt is enabled in embedded mode, create the API by >>> creating the registry artifact & database entry at the server startup. If >>> API mgt is enable in external mode call the jaggery endpoint (Publisher >>> API)for creating the API. >>> >>> Please advice. >>> >>> Thanks, >>> Lakmali >>> >>> >>> >>> Regards, >>>> Vijitha. >>>> >>>> >>>> On Tue, Jul 23, 2013 at 7:25 AM, Vijitha Kumara <viji...@wso2.com>wrote: >>>> >>>>> Hi All, >>>>> >>>>> On Fri, Jul 19, 2013 at 3:48 PM, Senaka Fernando <sen...@wso2.com>wrote: >>>>> >>>>>> Hi Nuwan, >>>>>> >>>>>> I believe that you should be able to determine the availability of >>>>>> the required components using @scr annotations isn't it? Before looking >>>>>> into other options such as onLogin, I think its best to experiment with >>>>>> that possibility which would make it possible for us to easily make use >>>>>> of >>>>>> option #2. >>>>>> >>>>> >>>>> In addition can we also make this configurable that is embedded or >>>>> external APIM? So that the user can set the appropriate URL for the latter >>>>> and the APIM component can lookup and publish if that is the case. Or an >>>>> optional config param only for an external APIM as we can use the default >>>>> URL in case with an embedded APIM. >>>>> >>>>> Also we need to make sure all possible basic use cases are covered >>>>> (when getting started) and user friendly specially when it is an OOTB >>>>> feature. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> Vijitha. >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Senaka. >>>>>> >>>>>> >>>>>> On Fri, Jul 19, 2013 at 3:39 PM, Sriragu Arudsothy >>>>>> <srir...@wso2.com>wrote: >>>>>> >>>>>>> Hi Nuwan, >>>>>>> >>>>>>> I agree to you. I also have done the second option >>>>>>> calling jaggery REST endpoint to publish the REST API. I tested using a >>>>>>> menu item click on it will publish the REST API after Greg server start >>>>>>> up. User who has certain permission may publish the REST API if not >>>>>>> published under the same tenant. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jul 19, 2013 at 3:20 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>>>>>> >>>>>>>> On Fri, Jul 19, 2013 at 2:59 PM, Senaka Fernando >>>>>>>> <sen...@wso2.com>wrote: >>>>>>>> >>>>>>>>> Hi Nuwan, >>>>>>>>> >>>>>>>>> I think the check at start-up is not going to be very expensive. >>>>>>>>> During server start-up we do several checks for services too. It will >>>>>>>>> become expensive if you try to do the same for all tenants of course. >>>>>>>>> Such >>>>>>>>> needs to happen when the tenant gets loaded. That's the standard >>>>>>>>> pattern >>>>>>>>> which is followed by all deployers. I believe API Mgt needs a similar >>>>>>>>> concept here. >>>>>>>>> >>>>>>>>> Understood. There is however another problem that will arise if >>>>>>>> we're going to create APIs at server startup. See explanation below. >>>>>>>> >>>>>>>> There are two ways that we can create the API. >>>>>>>> 1) Create the registry artifact and database entry. >>>>>>>> 2) Call the jaggery REST endpoint for creating the API. >>>>>>>> >>>>>>>> Both options will work with embedded API Management. But option 1 >>>>>>>> will not work with external API Management since we do not know the >>>>>>>> details >>>>>>>> of the API registry and DB. So when going with external API >>>>>>>> Management, we >>>>>>>> will have to go with option 2. Therefore it would be better to stick to >>>>>>>> option 2 for both cases since it'll be cleaner and have less >>>>>>>> complexity. For option 2 to work, the server should already be started. >>>>>>>> Therefore creating APIs at server startup in this manner would not be >>>>>>>> possible AFAIK. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> NuwanD. >>>>>>>> >>>>>>>> Thanks, >>>>>>>>> Senaka. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jul 19, 2013 at 2:48 PM, Nuwan Dias <nuw...@wso2.com>wrote: >>>>>>>>> >>>>>>>>>> On Fri, Jul 19, 2013 at 12:35 PM, Lakmali Baminiwatta < >>>>>>>>>> lakm...@wso2.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Nuwan, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 19 July 2013 12:19, Nuwan Dias <nuw...@wso2.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I think the API should initially be in a created state rather >>>>>>>>>>>> than being in a published state. The admin or whoever responsible >>>>>>>>>>>> should >>>>>>>>>>>> publish it through the publisher. >>>>>>>>>>>> >>>>>>>>>>>> We also need to make this a generic solution so that it works >>>>>>>>>>>> even with external API Management. When the API is added to the >>>>>>>>>>>> registry, >>>>>>>>>>>> it will be visible on the publisher (external). And when the admin >>>>>>>>>>>> goes and >>>>>>>>>>>> publishes it, the API will then be deployed onto the Store and >>>>>>>>>>>> Gateway. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> +1. Agree. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Lakmali >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> NuwanD. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Jul 19, 2013 at 12:10 PM, Lakmali Baminiwatta < >>>>>>>>>>>> lakm...@wso2.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> We have completed the implementation of the Embedded APIM >>>>>>>>>>>>> functionality, to manage GREG Rest APIs. We need to clarify how >>>>>>>>>>>>> are we >>>>>>>>>>>>> going to publish the GREG Rest API. Publishing the API includes >>>>>>>>>>>>> following >>>>>>>>>>>>> tasks, >>>>>>>>>>>>> >>>>>>>>>>>>> - Add the API artifact to the registry >>>>>>>>>>>>> - Add the API to the APIM database >>>>>>>>>>>>> >>>>>>>>>>>>> So we have three options to publish the API. >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Admin manually create the API and publish through API >>>>>>>>>>>>> Publisher app. (This is what we do at the moment) >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> Since we're publishing internal Product APIs here, this would not >>>>>>>>>> be a good option since users will not know what to publish and what >>>>>>>>>> information to enter. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 2. Publish the API at the server startup. >>>>>>>>>>>>> But since this is a one time operation, there >>>>>>>>>>>>> will be an overhead at each server startup, in checking whether >>>>>>>>>>>>> the API has >>>>>>>>>>>>> already published. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> Yes, as mentioned it would be an overhead to check whether the >>>>>>>>>> necessary APIs have been published at server startup. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 3. Publish the API at the GREG pack build time. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> This will work with embedded API Management but this is not a >>>>>>>>>> solution when going with External API Management. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> What would be the best option to procede with? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> Looking at the given options what I feel best is to have some >>>>>>>>>> kind of an Admin page where the Product's internal APIs are listed >>>>>>>>>> and and >>>>>>>>>> administrative user has the option of publishing them. Since we're >>>>>>>>>> talking >>>>>>>>>> about internal production APIs, it would also be fine to publish them >>>>>>>>>> directly rather than it first being in a created state. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> NuwanD. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Lakmali >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Lakmali Baminiwatta* >>>>>>>>>>>>> * >>>>>>>>>>>>> Software Engineer >>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>>>> blog : lakmali.com >>>>>>>>>>>>> * >>>>>>>>>>>>> * >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Dev mailing list >>>>>>>>>>>>> Dev@wso2.org >>>>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>> >>>>>>>>>>>> Senior Software Engineer - WSO2, Inc. http://wso2.com >>>>>>>>>>>> email : nuw...@wso2.com >>>>>>>>>>>> Phone : +94 777 775 729 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Lakmali Baminiwatta* >>>>>>>>>>> * >>>>>>>>>>> Software Engineer >>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>> blog : lakmali.com >>>>>>>>>>> * >>>>>>>>>>> * >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Nuwan Dias >>>>>>>>>> >>>>>>>>>> Senior Software Engineer - WSO2, Inc. http://wso2.com >>>>>>>>>> email : nuw...@wso2.com >>>>>>>>>> Phone : +94 777 775 729 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Dev mailing list >>>>>>>>>> Dev@wso2.org >>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> * <http://us13.wso2con.com/> >>>>>>>>> * >>>>>>>>> * >>>>>>>>> * >>>>>>>>> *Senaka Fernando* >>>>>>>>> Senior Technical Lead; WSO2 Inc.; http://wso2.com* >>>>>>>>> Member; Apache Software Foundation; http://apache.org >>>>>>>>> >>>>>>>>> E-mail: senaka AT wso2.com >>>>>>>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >>>>>>>>> Linked-In: http://linkedin.com/in/senakafernando >>>>>>>>> >>>>>>>>> *Lean . Enterprise . Middleware >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nuwan Dias >>>>>>>> >>>>>>>> Senior Software Engineer - WSO2, Inc. http://wso2.com >>>>>>>> email : nuw...@wso2.com >>>>>>>> Phone : +94 777 775 729 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> Dev@wso2.org >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> * <http://us13.wso2con.com/> >>>>>> * >>>>>> * >>>>>> * >>>>>> *Senaka Fernando* >>>>>> Senior Technical Lead; WSO2 Inc.; http://wso2.com* >>>>>> Member; Apache Software Foundation; http://apache.org >>>>>> >>>>>> E-mail: senaka AT wso2.com >>>>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >>>>>> Linked-In: http://linkedin.com/in/senakafernando >>>>>> >>>>>> *Lean . Enterprise . Middleware >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> Dev@wso2.org >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Vijitha Kumara >>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com/ >>>>> email: viji...@wso2.com >>>>> >>>>> >>>>> Lean . Enterprise . Middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> Vijitha Kumara >>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com/ >>>> email: viji...@wso2.com >>>> >>>> >>>> Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> Lakmali Baminiwatta* >>> * >>> Software Engineer >>> WSO2, Inc.: http://wso2.com >>> lean.enterprise.middleware >>> mobile: +94 71 2335936 >>> blog : lakmali.com >>> * >>> * >>> >> >> >> >> -- >> Lakmali Baminiwatta* >> * >> Software Engineer >> WSO2, Inc.: http://wso2.com >> lean.enterprise.middleware >> mobile: +94 71 2335936 >> blog : lakmali.com >> * >> * >> > > > > -- > /sumedha > b : bit.ly/sumedha > -- * <http://us13.wso2con.com/> * * * *Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com* Member; Apache Software Foundation; http://apache.org E-mail: senaka AT wso2.com **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando *Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
