+1 - more specifically, we want the Gateway to be embeddable in as many
environments and platforms as possible. Hence the desire for a small
footprint. As an example, relying on CDI when running the gateway in
Vert.x was not very appealing. But also we want users to be able to
easily embed the Gateway Engine in their own platforms.
-Eric
On 2/12/2016 7:06 AM, Marc Savy wrote:
I answered this already in IRC.
We can't rely upon CDI being available in the gateway environment, and
we didn't want to ship with a bundled CDI solution as they all tend to
be large with a substantial number of transitive dependencies and would
limit our ability to work on embedded platforms.
Regards,
Marc
On 12/02/2016 11:02, Charles Moulliard wrote:
> Hi,
>
> Is there a reason why the Apiman Gateway Services aren't injected using
> CDI like Apiman Manager ?
> Can we use for OSGI platform a different strategy to load the services
> and expose them (Apache Felix SCR annotations or Apache Aries Blueprint)
> as we have many issues with Resteasy deployed on Karaf like also to use
> Pax CDI ?
>
> Example : The Resteasy CDI Extension object is null when we call the
> BeanManager (created using PAx CDI Weld) to get the bean. This problem
> occurs not matter if we embed the Resteasy CDI extension within the
> bundle of Apiman Manager or as a bundle
>
> private ResteasyCdiExtension lookupResteasyCdiExtension() {
> Set<Bean<?>> beans =
manager.getBeans(ResteasyCdiExtension.class);
> Bean<?> bean = manager.resolve(beans);
> if (bean == null) {
> throw new
> IllegalStateException(Messages.MESSAGES.unableToObtainResteasyCdiExtension());
> }
>
> Regards,
>
> Charles
> _______________________________________________
> Apiman-dev mailing list
> Apiman-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/apiman-dev
>
_______________________________________________
Apiman-dev mailing list
Apiman-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-dev