I am working on a project that requires connecting to two different web services, so I have two web clients as dependencies (as JARs).
My problem is that only the handlers from one of the services are being called, the handlers from the other one are completely ignored. Both of the ws have a handler chain that works correctly in separate projects, but when combined, only one works.
I am defining the handler chain in handlers.xml.
Any suggestions?
I solved the problem. I was defining the handlers chain in two handlers.xml files, one for each of the services that I was using and the handlers classes and handlers.xml were included in the client jars. I moved the handlers definition in the web application, placed the handlers.xml in the classpath, defined handlers for both of the services in same file (using a condition to determine which handler should be executed) and the problem was solved.
I don't if the solution is correct or very elegant, but I'm not very familiar with SOAP handlers. If you have suggestions, feel free to comment/answer. Thanks!
Related
I am learning NativeScript + Angular2 with ServiceStack in C# as the backend.
For the app, I generated TypeScript classes using the typescript-ref command, for use with the JsonServiceClient in ServiceStack:
>typescript-ref http://192.168.0.147:8080 RestApi
It all looked sweet and dandy, until I discovered that it seems to ignore that the ServiceStack Services and Response DTOs are in different namespaces on the .NET side:
I have different branches of services, where the handlers for each service might differ slightly between the branches. This works well in ServiceStack, the Login and handlers work just as expected.
So, on the app/NativeScript/Angular2-side, I used the typescript-ref and generated the restapi.dtos.ts. The problem is it skips the namespace difference and just creates duplicate classes instead (from VSCode):
The backend WS in ServiceStack is built in this "branched" fashion so I don't have to start different services on different ports, but rather gather all of them on one port and keep it simple and clear.
Can my problem be remedied?
You should never rely on .NET namespaces in your public facing Services Contract. It's supported in .NET Clients but not in any other language which requires that each DTO be uniquely named.
In general your DTOs should be unique within your entire SOA boundary so that there's only 1 Test DTO which maps to a single schema definition which ensures that when it's sent through a Service Gateway, resolved through Service Discovery, published to a MQ Server, etc it only maps to a single DTO contract.
The visual studio project templates for a Service fabric services contains code that can be reused over other multiple projects. For example the ServiceEventSource.cs or ActorEventSource.cs
My programmer instinct wants to move this code to a shared library, so I don't have duplicate code. But maybe this isn't the way to go with microservices, since you want to have small independent services. Introducing a library will make it more dependent. But they are already dependent on the EventSource class.
My solution will be to move some reusable code to a base class in a shared project and inherit that class in my services. Is this the best approach?
I'm guessing all your services are going to be doing lots of different jobs so once you pad out your EventSource classes they'll be completely different from each other except one method which would be service started?
Like with any logging there is many different approaches, one of the main ones I like is using AOP or interceptor proxies using IoC containers, this will keeps your classes clean but allows re-use of the ETW code and a decent amount of logging to be able to debug later down the line.
I moved a lot of duplicate code to my own nuget libraries which is working quiet well. It is a extra dependency, but always better then duplicate code. Now I'm planning to make my one SF templates in visual studio, so I don't have to remove and adjust some files.
I found a nice library (EventSourceProxy) which helps me managing the EventSource code for ETW: https://github.com/jonwagner/EventSourceProxy
We are planning to use Drools/JBoss BRMS 6 for business rules management. Our plan is to write rules using the workbench, deploy the rules package in multiple Execution Servers and allow applications to access the Rules package by making calls to the REST API. We do not have any Java wrappers or custom classes in between the calling applications and the rules package.
I am trying to incorporate some logging into the rules engine. I understand that there are EventListener interfaces that can be implemented.
Please would you provide some information/guidance on how to implement Listeners in our kind of set up? Where will I create and store the Java classes/methods that would implement Event Listeners?
How can a calling application insert an Event Listener into the session? Will it be part of the xml/json payload?
Thanks
1. Where to implement the listeners?
The listeners must be obviously implemented in Java. One simple place I found to put those implementation is in a separate maven project. After all, a project in the kie-workbench is a maven project itself. So you can create a separate project (outside the kie-workbench) implement the listeners you want to and then add this new project as a dependency in your kie-workbench's project (check the documentation on how to do that).
The only problem I found with this approach is that once you defined the dependency between your projects, the kie-workbench will scan every single class of it and of any other dependency it has. Check this link for more information.
So, if your listener project doesn't have too many dependencies, you should be good to go. Please note that, in theory, you could add any kie/drools dependency you have in your listener project as <scope>provided</scope>.
2. How can I configure these listeners?
A trick that I always use is to have what I call a "configuration" rule to do this kind of job.
A "Configuration" rule is a rule without LHS (and, if you are distrustful, a high salience). This kind of rules are guaranteed to be executed only once. Just make sure that you call a fireAllRules() before the first interaction with the kie-server, or that the first interaction always starts with a fireAllRules command.
Your configuration rule could look like this:
/**
Configures the session's listeners.
**/
rule "[SUB-CONFIG] Listeners Configuration"
salience 1000
when
then
((org.drools.impl.StatefulKnowledgeSessionImpl)kcontext.getKnowledgeRuntime()).addEventListener(new MyWorkingMemoryEventListener());
((org.drools.impl.StatefulKnowledgeSessionImpl)kcontext.getKnowledgeRuntime()).addEventListener(new MyAgendaEventListener());
end
You can place this rule in your kie-server project.
Hope it helps,
I have a project which is basically an Apache Wicket web app, but it also has 3 REST services. I'd like to keep these two different technologies together in one application, as they share quite a lot of classes. Also, I'd like them to share the same JPA instance, as they operate on the same database.
The problem I'm facing is that, as soon as any JAX-RS path is specified, all URLs sent to the application appear to be handled by JAX-RS, even if the REST paths specified don't justify this. Concretely:
#PATH("service")
public class ServiceClassA
#PATH("s1")
public String someMethod...
#PATH("service")
public class ServiceClassB
...
Please note that thereby all defined services have a URI starting "MyAppName/service/...".
The Wicket classes are unaffected by this, as probably the Wicket filter runs before JAX-RS has a chance to grab the URL. But plain resources like css files get in the hands of JAX-RS, resulting in a
No root resource matching request path browser/xxx.css has been found, Relative Path: /browser/xxx.css.
The JAX-RS endpoints contain, in addition to those for the service methods shown above, a general one:
REST Application: http://localhost:8080/MyAppName/ -> org.apache.openejb.server.rest.InternalApplication
As soon as I remove all #PATH annotations, my css is served normally. So I suspect that the endpoint just shown is automatically generated and causes any URI of my app to be handled by the REST framework, even if no path was defined for it. So what I basically need is to tell JAX-RS to ignore
either all URIs not starting with "MyAppName/service",
or all URIs starting with "MyAppName/browser",
or to redirect all URIs it can't handle to the standard Web Server mechanism.
I experimented and googled for possible configuration options quite a lot, but still I didn't find anything suitable for such a simple requirement. I'd appreciate any hints.
BTW, my web.xml is plain vanilla. It contains the wicket filter, mapped to /*, and nothing else, in particular no filtering or servlet for JAX-RS. The server is TomEE-plus 1.6.0.2, and the JAX-RS libraries are the ones shipped with TomEE.
JAX-RS is a servlet so without binding it to a sub context of your app it conflicts with resources. You can provide an Application with #Application("subcontext").
Note: TomEE supports exclusion of some static resources but the configuration is explicit in openejb-jar (https://issues.apache.org/jira/browse/TOMEE-728) so first solution is easier.
In MVC3 application I have my custom implementation of IPrincipal.
I want to register it in web.config and then inject it to constructors by Autofac.
Autofac XML-configuration has attribute "instance-scope" but it does not support "per-http-request".
Any ideas how can I register component per http scope in web.config?
I already tried different combinations of per-dependency, single-instance or per-lifetime-scope with ownership external but results are very buggy.
As Nicholas Blumhardt from Autofac team told me per-lifetime-scope should be used.
When running under ASP.NET it is equivalent to per-HTTP-request in practical terms.
As far as I can see from the source, registering per http request in XML configuration is not supported. As you mention, only the three instance-scope values (per-dependency, single-instance and per-lifetime-scope) are allowed.
Also, looking at how per-http-request scoping works, it uses the InstancePerMatchingLifetimeScope registration call with a httpRequest key. Again, there is no XML config way of configuring a "matching-lifetime-scope".
The way to go is configuration through code.