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...
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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
