Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jersey contextConfig support #26

Closed
Jotschi opened this issue Nov 26, 2014 · 5 comments
Closed

Jersey contextConfig support #26

Jotschi opened this issue Nov 26, 2014 · 5 comments

Comments

@Jotschi
Copy link
Contributor

Jotschi commented Nov 26, 2014

It would be great if it would be possible to add support for the contextConfig resource config setting. In my case the setting is a spring AnnotationConfigApplicationContext object. The object can't be passed on to the DefaultJerseyOptions via the vert.x config mechanism. Do you have an idea how to handle this setting? I added a static setter to the DefaultJerseyOptions class in order to test it.

@adrianluisgonzalez
Copy link
Member

Do you have a snippet you can post? I don't follow what you mean by:
add support for the contextConfig resource config setting

Do you need a way to control creation of the ResourceConfig? You can extend DefaultJerseyOptions and override getResourceConfig() and do whatever you need. Does that help?

@Jotschi
Copy link
Contributor Author

Jotschi commented Dec 2, 2014

Yes that helps. How can i unbind the DefaultJerseyOptions? The HK2JerseyBinder is binding and my own binder is used once the DefaultJerseyOptions has already been used.

public class JerseyOptionsWithContextInfo extends DefaultJerseyOptions {

    public static Object context;

    @Inject
    public JerseyOptionsWithContextInfo(@Optional ServiceLocator locator) {
        super(locator);
    }

    @Override
    protected ResourceConfig getResourceConfig() {
        ResourceConfig rc = super.getResourceConfig();
        if (context != null) {
            rc.property("contextConfig", context);
        }
        return rc;
    }

}
/**
 * HK2 Jersey binder
 */
public class AppBinder extends AbstractBinder {

    @Override
    protected void configure() {
        bind(JerseyOptionsWithContextInfo.class).to(JerseyOptions.class);
    }

}

@Jotschi
Copy link
Contributor Author

Jotschi commented Dec 2, 2014

My idea was to replace DefaultJerseyOptions with the JerseyOptionsWithContextInfo class but i just noticed that the DefaultJerseyOptions are responsible for handling the binders option. Do you have a suggestion on how to deal with this usecase?

@Jotschi
Copy link
Contributor Author

Jotschi commented Dec 2, 2014

Got it!

I'm now extending the HK2JerseyBinder and using the _hk2_binder_ config instead of _binders_.

/**
 * HK2 Jersey binder
 */
public class AppBinder extends HK2JerseyBinder {

    @Override
    protected void configure() {
        bind(JerseyOptionsWithContextInfo.class).to(JerseyOptions.class);
        super.configure();
    }

}

@Jotschi Jotschi closed this as completed Dec 2, 2014
@adrianluisgonzalez
Copy link
Member

Yes, that is what I was thinking.

Two things to consider:

  1. You can, but don't need to extend HK2JerseyBinder. Alternatively you can specify multiple binders as a json array in config or you can call install(new HK2JerseyBinder()); from your binder. All three approaches should work fine.
  2. You should probably set the rank to ensure your implementation of JerseyOptions is chosen: bind(JerseyOptionsWithContextInfo.class).to(JerseyOptions.class).ranked(10);

https://hk2.java.net/2.3.0/apidocs/org/glassfish/hk2/utilities/binding/ServiceBindingBuilder.html#ranked(int)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants