Re: CDI?
Weird, I didn't see this last year after you posted it. I don't know why. I
was up here reading on the latest as I'm going to be doing some prototyping
with Fuse 7 and wanted to see what latest best practices are and where CDI
is after the February release date.
I probably should write a blog/tutorial on this stuff. Using Mockito to
mock OSGi injection, pojos (not Processors/Exchanges) and using standard
Camel Java DSLs and CamelTestSupport make testing simple. Part of the
problem I've found with the Blueprint implementation of Camel is if one
uses the XML the routes are stuck in the Camel context and can't be broken
down into sub-routes for easy testing. The CamelRouteBuilder mitigates that
a lot. So you get an onion peel testing of JUnit for basic handlers,
Mockito for injecting OSGi mock services, CamelTestSupport for testing the
wire up of handlers and eips with mock services (you have to use the JNDI
registry in CamelTestSupport and not the OSGi service registry), and only
use the CamelBlueprintTestSupport for a general sanity check that
everything is wired and spelled correctly.
One downside is that I end up using the Camel annotations for injection
then and not CDI or other standard. A small price I guess...I just keep
hoping we get the best of all worlds at some point with CDI for easy wire
up and DS mechanics under the covers.
For CXF services I usually use both SOAP and REST annotations on an
interface and then use a Camel route with either a recipientList using the
operation name to specify an immediate endpoint or I use the
toD(direct"${operationName}") to hit a route (I'm writing that off the top
of my head so may be misrecalling the variable). However, I've also inject
OSGi services into the CXF bundle and have every method on the web service
invoke the same direct: endpoint which has a single bean on it - the
injected OSGi service. Camel uses reflection to select the correct method
to invoke. That works as long as the requests are uniquely named. Otherwise
it's back to using the recipientList or toD variant. That means that Camel
and CXF live in one bundle and the OSGi service just gets messages. I
should mention that I usually use canonical domain objects so before the
OSGi service actually gets invoked I'm transforming using Dozer into a
canonical domain model. That way I don't get protocol/transport artifacts
like XMLGregorianCalendar leaking into the rest of the world.
But I use a variety of messaging and not just web services. That's where
routing between bundles with Camel can be quite beneficial. I might use
SEDA (VM) during development or even deployment and use a string
interpolation injected via @PropertyInject for that endpoint and set it in
the Blueprint by default but can override it in the pid.cfg file. That way
if I move a bundle the servicing bundle to another container I can change
the endpoint to a amq: or whatever else it might be. That's rare. More
usual reasons for changing it would be if the incoming event or any even is
transactional and I want to drop it on a persistent queue before returning
an ACK to the client that things are OK.
But that use case is what I meant by it being loosely coupled. If I'm using
SEDA on a route and CXF receives an incoming event, converts the object to
a domain model sans JAXB/XML elements, and then sends it on an endpoint, I
don't need to decide what the endpoint is until runtime. Default of SEDA/VM
for development and then it may or may not be the same when deployed
depending on where the consuming bundle lives.
On Wednesday, August 16, 2017 at 3:42:13 PM UTC-5, Christian Schneider
wrote:
>
> On 15.08.2017 16:06, ra...@enjekt.org wrote:
>
> Christian,
>
> I've also seen a lot of people using Processors/Exchanges which
> unnecessarily couples their cod to the Camel framework. Unfortunately the
> Camel in Action book doesn't get around to advising against that practice
> until your well over 100 pages into the books. And when it does it is in a
> bulleted list at the end of a chapter. When I'm at client sites it's one of
> the first things I teach them when mentoring developers. Use POJOs and unit
> tests just like any other code. Unfortunately neither the Camel website nor
> the Camel in Action book stress this and too many code examples use
> Processor/Exchanges unnecessarily. Honestly, in the past six years, I don't
> recall the last time I used Camel Processor/Exchange directly.
>
> I think you are on a very good track with this approach and it would be
> good to spread the word about it. As you wrote it is not emphasized enough
> in the camel book. So if you have a blog that would be a great theme.
>
> But services aren't more loosely coupled than messaging. If I have bundle
> A with all its classes unexported in ".internal" package and bundle B in
> the same situation but they communicate via Camel routes, that's decoupled
> at compile time and at runtime.
Shared Filter with a Wab
Hello! I'm having trouble to use a SharedContext filter within some WAB resources. I've created a filter using blueprint and exposed it as a shared Context like this: And i need all my wab bundles, which contains mostly static resources to pass through this filter, how can i do that? The bundles are created using the Web-ContextPath directive at the MANIFEST.MF. -- -- -- OPS4J - http://www.ops4j.org - ops4j@googlegroups.com --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [PAX-WEB] WebContainer - registering ServletFilter - confusion
From: ops4j@googlegroups.com [mailto:ops4j@googlegroups.com] On Behalf Of Grzegorz Grzybek Sent: Mittwoch, 17. Oktober 2018 09:23 To: ops4j@googlegroups.com Subject: Re: [PAX-WEB] WebContainer - registering ServletFilter - confusion if you want global filters or prometheus integration (I imagine it like single endpoint, like /health or /metrics or something) you could try doing something container (jetty/undertow/tomcat) specific. Tomcat has valves, jetty and undertow have handlers - you can look at the code to check how for example NSCA logging interceptor/handler/valve is implemented. What would be the right place to register my handler directly on Jetty? It is somewhere created internally in Pax-Web and it is not exposed to OSGi context Best regards, Lukasz Lech -- -- -- OPS4J - http://www.ops4j.org - ops4j@googlegroups.com --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PAX-WEB] WebContainer - registering ServletFilter - confusion
Hello
śr., 17 paź 2018 o 08:44 Lukasz Lech napisał(a):
> OK thank you, I’ll try that way.
>
>
>
> So I need either to implement a bundle that will get the names of other
> bundles it should register metrics for, or I should build metrics in
> specific bundles, and in case I’d like to have karaf-wide Prometheus
> metrics collection I’d need to modify WebContainer implementation?
>
if you want global filters or prometheus integration (I imagine it like
single endpoint, like /health or /metrics or something) you could try doing
something container (jetty/undertow/tomcat) specific. Tomcat has valves,
jetty and undertow have handlers - you can look at the code to check how
for example NSCA logging interceptor/handler/valve is implemented.
>
>
> Are there any plans to provide build-in Prometheus metrics collection in
> pax-web?
>
You could even provide a solution for pax-web ;) For now pax-web isn't
prometheus-aware, but I could imagine some kind of integration.
regards
Grzegorz Grzybek
>
>
> Best regards,
>
> Lukasz Lech
>
>
>
>
>
> *From:* ops4j@googlegroups.com [mailto:ops4j@googlegroups.com] *On Behalf
> Of *Grzegorz Grzybek
> *Sent:* Mittwoch, 17. Oktober 2018 08:14
> *To:* ops4j@googlegroups.com
> *Subject:* Re: [PAX-WEB] WebContainer - registering ServletFilter -
> confusion
>
>
>
> Hello
>
>
>
> First, the most important line in your code is:
>
>
>
> WebContainer webContainer = (WebContainer) context.getService(reference);
>
>
>
> And especially "context" you're using. pax-web in general and
> "registerFilter()"
> method in particular is an attempt to implement concepts from javax.servlet
> specification (concepts from WEB-INF/web.xml) in OSGi.
>
> Short - you're registering filter in different context than the one you
> have your servlets you want to filter. Even in JavaEE you can't have a
> filter that's filtering servlets in different contexts.
>
>
>
> You can however grab a BundleContext from different bundle - just get the
> single (or even more) Bundle from context.getBundles() by symbolic name for
> example and get its context - then grab WebContainer service from this
> context instead of the context you're given in BundleActivator.start().
>
>
>
> regards
>
> Grzegorz Grzybek
>
>
>
> wt., 16 paź 2018 o 15:05 Lukasz Lech napisał(a):
>
> Hello,
>
>
>
> I’m trying to register io.prometheus.client.filter.MetricsFilter for
> Prometheus metrics.
>
>
>
> I’m trying to call registerFilter() with many possible url patterns, but
> none seem to have any affect:
>
>
>
> @Override
>
> public void start(BundleContext context) throws Exception
>
> {
>
> webContainerTracker = new WebContainerTracker(context);
>
> webContainerTracker.open();
>
> }
>
>
>
> @Override
>
> public Object addingService(ServiceReference reference)
>
> {
>
> WebContainer webContainer = (WebContainer)
> context.getService(reference);
>
> this.metricsFilter = new MetricsFilter();
>
> webContainer.registerFilter(metricsFilter, new String[]{"/", "*",
> "/*"}, null, null, false, null);
>
> return webContainer;
>
> }
>
>
>
> Expected behavior:
>
> Any request to Karaf, including opening WebConsole, would land me in
> MetricsFilter.doFilter breakpoint
>
> Observed behavior:
>
> Nothing, even init() method is not called.
>
>
>
> Do wildcards are supported by WebContainer for registering filters? Or not
> every request goes through that filters, and I’d need to register filter on
> jetty directly? (how?, Jetty seems not to be exposed in OSGi context).
>
>
>
> I’m using JaxRS-Publisher that registers servlets using
> HttpService.addServlet() (and WebContainer is the only available
> implementation).
>
>
>
> WebConsole also uses WebContainer, so I assume, it must register servlets
> also using that method.
>
>
>
> Where is the problem? What I’m doing wrong?
>
>
>
> Best regards,
>
> Lukasz Lech
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit
Re: [PAX-WEB] WebContainer - registering ServletFilter - confusion
Hello
First, the most important line in your code is:
WebContainer webContainer = (WebContainer) context.getService(reference);
And especially "context" you're using. pax-web in general and
"registerFilter()"
method in particular is an attempt to implement concepts from javax.servlet
specification (concepts from WEB-INF/web.xml) in OSGi.
Short - you're registering filter in different context than the one you
have your servlets you want to filter. Even in JavaEE you can't have a
filter that's filtering servlets in different contexts.
You can however grab a BundleContext from different bundle - just get the
single (or even more) Bundle from context.getBundles() by symbolic name for
example and get its context - then grab WebContainer service from this
context instead of the context you're given in BundleActivator.start().
regards
Grzegorz Grzybek
wt., 16 paź 2018 o 15:05 Lukasz Lech napisał(a):
> Hello,
>
>
>
> I’m trying to register io.prometheus.client.filter.MetricsFilter for
> Prometheus metrics.
>
>
>
> I’m trying to call registerFilter() with many possible url patterns, but
> none seem to have any affect:
>
>
>
> @Override
>
> public void start(BundleContext context) throws Exception
>
> {
>
> webContainerTracker = new WebContainerTracker(context);
>
> webContainerTracker.open();
>
> }
>
>
>
> @Override
>
> public Object addingService(ServiceReference reference)
>
> {
>
> WebContainer webContainer = (WebContainer)
> context.getService(reference);
>
> this.metricsFilter = new MetricsFilter();
>
> webContainer.registerFilter(metricsFilter, new String[]{"/", "*",
> "/*"}, null, null, false, null);
>
> return webContainer;
>
> }
>
>
>
> Expected behavior:
>
> Any request to Karaf, including opening WebConsole, would land me in
> MetricsFilter.doFilter breakpoint
>
> Observed behavior:
>
> Nothing, even init() method is not called.
>
>
>
> Do wildcards are supported by WebContainer for registering filters? Or not
> every request goes through that filters, and I’d need to register filter on
> jetty directly? (how?, Jetty seems not to be exposed in OSGi context).
>
>
>
> I’m using JaxRS-Publisher that registers servlets using
> HttpService.addServlet() (and WebContainer is the only available
> implementation).
>
>
>
> WebConsole also uses WebContainer, so I assume, it must register servlets
> also using that method.
>
>
>
> Where is the problem? What I’m doing wrong?
>
>
>
> Best regards,
>
> Lukasz Lech
>
>
>
> --
> --
> --
> OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
>
> ---
> You received this message because you are subscribed to the Google Groups
> "OPS4J" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ops4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
--
--
OPS4J - http://www.ops4j.org - ops4j@googlegroups.com
---
You received this message because you are subscribed to the Google Groups
"OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ops4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
