سؤال

I want to configure a self-written JCA 1.6 inbound resource adapter (RA). My big problem is that the RA needs to get access to some (dynamic) configuration data living in the application that uses the RA. Now I know that this is against the original idea of the whole JCA idea but unfortunately I cannot change this design as quickly as I'd like/have to. The data I need to get to the RA is

  • the port it's supposed to listen on,
  • the license used for the whole application (the feature the RA supplies requires extra licensing)
  • additional configuration data stored in a db

I've come up with four ideas:

  1. Use the asadmin create-resource-adapter-config. Due to the fact that glassfish doesn't seem to restart apps depending on the RA, we need to restart the application after this. While this attempt is suitable for the port, it won't fit for the other data.
  2. Use administered objects to give my application a means to pass data in to the RA. This idea is mentioned here. I guess this does it, but the spec states in chapter 13.4.2.3 that

    Note, administered objects are not used for setting up asynchronous message deliveries to message endpoints. The ActivationSpec JavaBean is used to hold all the necessary activation information needed for asynchronous message delivery setup.

    But I cannot get any dynamic data to the ActivationSpec object (neither through a DeploymentDescriptor nor through annotations). Or did I miss something here? :-)

  3. Use JDBC directly to access the data (also grabbed the idea from here). While this is presumably the best idea, it does not work for the mentioned licensing data as it is not stored in the db.

  4. The last idea I had was to put a method in the MessageDrivenBean (through my interface) that is used to fetch data from within the RA. That method could be called from the RA and would supply the data. But: I just think that is quite abusive as it couples the RA to the app.

Dear community, what are your thoughts on this one? I'm afraid it's not so easy to find answers to these questions, so I'd be quite happy about opinions!

Thanks and cheers, Julius

هل كانت مفيدة؟

المحلول 2

The solution I finally came up with is to use the @ConfigProperty annotation. This means I use option one of my question above.

So my ResourceAdapter class looks like this:

public class Hl7ResourceAdapter implements ResourceAdapter {
    @ConfigProperty
    private Integer port = null;

    // Rest from ResourceAdapter interface omitted here...

    // Use port here to open socket...
}

The @ConfigProperty fields can now be set through either

  • a resource-adapter-config
  • the ra.xml deployment descriptor

Now in order to reconfigure these settings I use glassfish's REST interface to change these settings programmatically (one could also use the asadmin create-resource-adapter-config command). I circumvent the problem, that glassfish does not restart the application that uses the resource adapter by simply restarting it myself through REST. (To be precise: I disable the application and then reenable it to get around another bug in glassfish)

A few additional notes:

  • We deploy the resource adapter's .rar file into the .ear of the application using it.
  • We have a separate application outside glassfish (standalone) that calls the REST interface to do such things as restart the resource adapter application etc. It is obvious that an application cannot restart itself properly.

Hope this helps. kutuzof, will this get you any further?

نصائح أخرى

In the ra.xml there is the possibility to define config-properties. In Websphere these then show up as editable fields in a table of custom properties for the selected resource adapter. I'm working on a similar problem, I also need to pass hostname / port info to an RA. Unfortunately I haven't figured out how to read the contents of these fields from within the RA however.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top