Develop Reference

Dropwizard registering two classes/clients

I have two instances of clients with different configs that I am creating (timeout, threadpool, etc...), and would like to leverage Dropwizard's metric on both of the clients.
final JerseyClientBuilder jerseyClientBuilder = new JerseyClientBuilder(environment)
.using(configuration.getJerseyClientConfiguration());
final Client config1Client = jerseyClientBuilder.build("config1Client");
environment.jersey().register(config1Client);
final Client config2Client = jerseyClientBuilder.build("config2Client");
environment.jersey().register(config2Client);
However, I am getting
org.glassfish.jersey.internal.Errors: The following warnings have been detected:
HINT: Cannot create new registration for component type class org.glassfish.jersey.client.JerseyClient:
Existing previous registration found for the type.
And only one client's metric shows up.
How do I track both clients' metrics or is it not common to have 2 clients in a single dropwizard app?

Never mind, turned out I was an idiot (for trying to save some resource on the ClientBuilder).
2 Things that I did wrong with my original code:
1. You don't need to register Jersey clients, just the resource is enough... somehow I missed the resource part in my code and just straight up trying to register the client
2. You need to explicitly build each JerseyClientBuilder and then build your individually configured clients, then dropwizard will fetch by each JerseyClientBuilder's metrics
In the end, I just had to change my code to the following:
final Client config1Client = new JerseyClientBuilder(environment)
.using(configuration.getJerseyClientConfiguration()).build("config1Client");
final Client config2Client = new JerseyClientBuilder(environment)
.using(configuration.getJerseyClientConfiguration()).build("config2Client");
Doh.

environment.jersey().register() has a javadoc listing of Adds the given object as a Jersey singleton component meaning that the objects registered become part of the jersey dependency injection framework. Specifically this method is used to add resource classes to the jersey context, but any object with an annotation or type that Jersey looks for can be added this way. Additionally, since they are singletons you can only have one of them per any concrete type (which is why you are getting a "previous registration" error from Jersey).
I imagine that you want to have two Jersey clients to connect to two different external services via REST/HTTP. Since your service needs to talk to these others to do its work, you'll want to have the clients accessible wherever the "work" or business logic is being performed.
For example, this guide creates a resource class that requires a client to an external http service to do currency conversions. I'm not saying this is a great example (just a top google result for dropwizard external client example). In fact, I think this not a good to structure your application. I'd create several internal objects that hide from the resource class how the currency information is fetched, like a business object (BO) or data access object (DAO), etc.
For your case, you might want something like this (think of these as constructor calls). JC = jersey client, R = resource object, BO = business logic object
JC1()
JC2()
B1(JC1)
B2(JC2)
R1(B1)
R2(B2)
R3(B1, B2)
environment.jersey().register(R1)
environment.jersey().register(R2)
environment.jersey().register(R3)
The official Dropwizard docs are somewhat helpful. They at least explain how to create a jersey client; they don't explain how to structure your application.
If you're using the Jersey client builder from dropwizard, each of the clients that you create should be automatically registered to record metrics. Make sure you're using the client builder from the dropwizard-client artifact and package io.dropwizard.client. (Looks like you are because you have the using(config) method.)

How does one dynamically agree on a SenderCompID and TargetCompID in quickfixj?

Suppose that I'm running a web-based exchange and a new customer signs up. I give that customer a new CompID and now I want to add that CompID to my acceptor. Do I have to restart my acceptor or can that be done dynamically?
It doesn't seem very scalable to have to agree on the CompID ahead of time and then sticking it in a configuration somewhere.
I've seen some examples which supposedly do that, but they seem to simply change the configuration to pretty much ignore the Sender/Target CompID's by setting them to *. Any other ways to do that?

Take a look at the DynamicAcceptorSessionProvider and how it's used in the Executor example. The Executor example reads session "templates" from the settings file and associates these with the acceptor endpoint IP address. An acceptor template is identified by the "AcceptorTemplate=true" setting. Any of the session ID fields, including the FIX version, can be wildcarded, not just the SenderCompID.
See the executor_dynamic.cfg for an example of how session templates are defined. In this configuration, both the SenderCompID and TargetCompID are wildcarded and templates for various FIX versions are defined (to specify the appropriate data dictionary file).
When a message arrives for an unknown session ID, the DynamicAcceptorSessionProvider will try to match the session ID with a template's wildcarded sessionID. If it finds a match, the new session will be created automatically and added to the acceptor as if it had been explicitly defined in the settings. The new session will have the settings defined in the acceptor session template.
The DynamicAcceptorSessionProvider is an AcceptorSessionProvider implementation that uses the settings file to support dynamic session creation. However, you could also implement a custom AcceptorSessionProvider that could dynamically create sessions based on database information, for example.

I think you want to fix the TargetCompID and send a unique SenderCompID for each user to use. Then you set the SenderCompID in your acceptor config to *. This will allow the acceptance of all SenderCompIDs. However you will need to have somewhere in your code the facility to check each order against your database of users. If the user(SenderCompID) is not valid then you will send a reject message. Many implementations will also use tunnels and whitelisted IP addresses as well to make sure no unwanted connections are coming in.

Insert MBean interceptor

I am working in a java project which implements MBeans and my need is to intercept MBean and change/add their properties before registry. Example :
domainName:name=myMBean --> domainName:name=myMBean1,type=myType
I found this link which presents how to apply an interceptor other then default interceptor but I have no idea to how do that in code.
Thanks in advance.

Once you register the bean obviously it is too late. The easiest thing to do is to change how the registration is done. If you show us what framework you are using to register the bean then I'll be able to help more.
Typically whatever is doing the actual registration is doing something like:
private MBeanServer mbeanServer;
...
mbeanServer.registerMBean(mbean, objectName);
You can therefore provide a different ObjectName:
ObjectName objectName = new ObjectName("domainName:name=myMBean1,type=myType");
But I assume you are not doing the registration yourself.
As an aside, I'm not sure you can switch to use a different JMX framework but I've put the finishing touches on my Simple JMX system recently. It allows objects to name themselves programmatically when they are published.

a spring bean to wrap salesforce web service calls

I am trying to figure out how to create a stateless spring bean that wraps a group of calls to salesforce web service API. My understanding is that the process for calling salesforce is something like this:
Call the login service to Log into salesforce
Make a series of service calls
Call the logout
To have a stateless wrapper it seems right pattern is to have each method in the bean perform all three steps above. e.g. (pseudocode)
binding.login();
binding.upsert(….);
binding.upsert(….);
binding.logout();
Is this a good practice? It seems it would be a costly way just to keep the bean stateless. Would it be preferable in this instance to make the bean request scope?

I agree with Anup, you should take a look at the sfdc wsc.
If you want go entirely stateless you will need to know the following things about a salesforce connection.
every action must have an endpoint url, something like na6.salesforce.com or na7.salesforce.com
every action must have a valid SID(session id) for the action to complete.
When you login to salesforce the original endpoint is login.salesforce.com and if you are sucessfull you will be returned a valid endpoint(na6.salesforce.com) and a SID.
You can then drop that endpoint/sid into a singleton and share it with as many spring beans as you want. In each bean you will need to create a new SoapBindingStub and set the endpoint and sid before you execute an insert/upsert/update/etc. action.
That sid will expire after a period of inactivity (anywhere from 30-120 minutes depending upon setting) so you should catch any exceptions and relogin using the singleton object.
Dont worry about two beans casuing the singleton relogin at the same time because salesforce will return the sames sid to both.

Have you tried SFDC WSC library? It's easy to use, and fits the use case that you are trying to accomplish.

Best way to show the user full name in a JSP header file with a spring/struts framework?

I have a JSP struts application that uses Spring to integrate with the services/dao/database. Basically, struts uses spring to get the data from the DB, it builds the form and forward them to the JSP files.
I have a header file that is injected in each JSP file using Tiles. I would like to show "Welcome John Doe" on each page inside the header. Where "John Doe" is the name of the currently logged user.
What would be the best approach to do that? The solution that I can think of is:
Use a Spring Filter the catch the http request. Load the user from the database using a cookie that contains the user id(*) and put the name in a session bean named "CurrentUser"
In "header.jsp", get the spring application context. Using it, load the bean "CurrentUser" and get the name. Put the name in the html.
I think I could get this to work. But I'm not certain this is the best way to do it. Any thought on my approach?
(*) Of course, the cookie will be encrypted

Although it may be an extremely large hammer for your fairly simple use-case, we have gotten a really neat spring-jsp integration (jsp 2.1 required!) by using ELResolver. By following this tutorial you can basically inject any spring managed bean into your el-context and allow it to be accessed using jsp-el like this:
${spring.mybean.myproperty}
You can choose to inject pre-defined beans into your el-context or simply pass "mybean" to getBean and allow almost anything spring-managed to be accessible from jsp. mybean could easily be a session-scoped spring bean.
I'm not totally sure how this would align with tiles, though.

Are you not already storing some sort of User object in Session?
If so, I would just add a "getFullName()" method to this domain object and have the DAO populate it when it returns it. Ideally you should populate the User object when the user logs in, store it in session, and not need to load all of the user's details again from the database on each and every page request.
(Are you not using Spring Security? If so, they provide a pretty simple way to store a UserDetails-like object in Session, and easy access to it.)
I'd vote against both of your approaches because
This means (at least) an extra database call per page request
This wouldn't work if other users shared the same bean in the same context. Also, you really shouldn't have JSP files (which are your presentation layer) interacting with data services directly.