On Sun, Aug 4, 2013 at 6:21 PM, Lakmali Baminiwatta <[email protected]>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 <[email protected]> wrote: > >> 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 >> * >> * >> > > > > -- > Lakmali Baminiwatta* > * > Software Engineer > WSO2, Inc.: http://wso2.com > lean.enterprise.middleware > mobile: +94 71 2335936 > blog : lakmali.com > * > * > -- /sumedha b : bit.ly/sumedha
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
