Hi all,
On 26 July 2013 06:25, Vijitha Kumara <[email protected]> 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 <[email protected]> wrote: > >> Hi All, >> >> On Fri, Jul 19, 2013 at 3:48 PM, Senaka Fernando <[email protected]> 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 <[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 >>> >>> >> >> >> -- >> Vijitha Kumara >> Senior Software Engineer; WSO2, Inc.; http://wso2.com/ >> email: [email protected] >> >> >> Lean . Enterprise . Middleware >> > > > > -- > Vijitha Kumara > Senior Software Engineer; WSO2, Inc.; http://wso2.com/ > email: [email protected] > > > Lean . Enterprise . Middleware > -- 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
