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.
Thanks, Senaka. On Fri, Jul 19, 2013 at 3:39 PM, Sriragu Arudsothy <[email protected]> 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 <[email protected]> wrote: > >> On Fri, Jul 19, 2013 at 2:59 PM, Senaka Fernando <[email protected]> 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 <[email protected]> wrote: >>> >>>> On Fri, Jul 19, 2013 at 12:35 PM, Lakmali Baminiwatta <[email protected] >>>> > wrote: >>>> >>>>> Hi Nuwan, >>>>> >>>>> >>>>> On 19 July 2013 12:19, Nuwan Dias <[email protected]> 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 < >>>>>> [email protected]> 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 >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nuwan Dias >>>>>> >>>>>> Senior Software Engineer - WSO2, Inc. http://wso2.com >>>>>> email : [email protected] >>>>>> 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 : [email protected] >>>> Phone : +94 777 775 729 >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> 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 : [email protected] >> Phone : +94 777 775 729 >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> 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 [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
