Folks,
There is already a @Service called JmsProviderLifecycle (as a part of
the JMS module) that handles start-up of the broker. I can modify this
to provide a public method to start the broker on demand. I don't think
it is a good idea to have the broker initialization code in multiple
places.
Also, the dependency on the connector-runtime in the below code is due
to ConnectorRegistry.getInstance().getActiveResourceAdapter(module);.
You probably don't need this if you don't need a reference to the
ResourceAdapter instance in your code.
Thx,
Satish
Jerome Dochez wrote:
> I am proposing to have MQInitializer interface become a @Contract
> inside internal-api
>
> @Contract
> public interface MQInitializer {
> }
>
> inside connectors-runtime.jar module, have
>
> @Service
> public class MQInitializerImpl implements MQInitializer, PostContruct {
>
> // not sure why this is useful, since you don't use it below but I put
> it for completeness
> @Inject
> ConnectorRuntime cr;
>
> public void postConstruct() {
> //Start ActiveJMSResourceAdapter.
> //ActiveJmsResourceAdapter air = (ActiveJmsResourceAdapter)
> java.security.AccessController.doPrivileged(
> new java.security.PrivilegedExceptionAction() {
> public Object run() throws Exception {
> final String module = ConnectorConstants.DEFAULT_JMS_ADAPTER;
> final String loc =
> ConnectorsUtil.getSystemModuleLocation(module);
> connectorRuntime.createActiveResourceAdapter(loc, module,
> null);
> return
> ConnectorRegistry.getInstance().getActiveResourceAdapter(module);
> }
> });
> }
>
> }
>
> your code (with java coding style respected...) :
>
> public void loadJMSBroker()
> {
> try {
> final MQInitializer mqi
> = InjectedValues.getInstance().getHabitat().getByContract(
> MQinitializer.class );
> if ( == null ) {
> throw new IllegalStateException("Can't obtain
> ConnectorRuntime" );
> }
> } catch( final Exception e ){
> ImplUtil.getLogger().log( Level.INFO, "Could not load JMS
> broker", e);
> }
> }
>
> that way, AMX just depends on internal-api, which it probably already
> does.
>
> On Sep 22, 2009, at 7:26 PM, Lloyd Chambers wrote:
>
> I'm pleased to avoid any new dependencies, but I don't understand the
> proposal.
>
> This is what's being done:
>
> import com.sun.enterprise.connectors.ConnectorRuntime;
> import com.sun.appserv.connectors.internal.api.ConnectorConstants;
> import com.sun.appserv.connectors.internal.api.ConnectorsUtil;
> import com.sun.enterprise.connectors.ConnectorRegistry;
> ...
>
>
> protected void
> getMQAdapter( final ConnectorRuntime connectorRuntime) throws Exception {
> //Start ActiveJMSResourceAdapter.
> //ActiveJmsResourceAdapter air = (ActiveJmsResourceAdapter)
> java.security.AccessController.doPrivileged(
> new java.security.PrivilegedExceptionAction() {
> public Object run() throws Exception {
> final String module = ConnectorConstants.DEFAULT_JMS_ADAPTER;
> final String loc =
> ConnectorsUtil.getSystemModuleLocation(module);
> connectorRuntime.createActiveResourceAdapter(loc, module,
> null);
> return
> ConnectorRegistry.getInstance().getActiveResourceAdapter(module);
> }
> });
> }
>
> public void
> loadJMSBroker()
> {
> try
> {
> final ConnectorRuntime connectorRuntime =
> InjectedValues.getInstance().getHabitat().getByType(
> ConnectorRuntime.class );
> if ( connectorRuntime == null ) {
> throw new IllegalStateException("Can't obtain
> ConnectorRuntime" );
> }
> getMQAdapter( connectorRuntime );
> }
> catch( final Exception e ){
> ImplUtil.getLogger().log( Level.INFO, "Could not load JMS
> broker", e);
> }
> }
>
>
>
>
> On Sep 22, 2009, at 5:36 PM, Jerome Dochez wrote:
>
>> I don't think this import is right. Outside if obvious modularity
>> concerns, this would make connector runtime mandatory is less
>> sophisticated distributions. Looks like we should have interfaces in
>> internal-api, impl in connector rutime and AMX should look up the
>> impl in the habitat(with a potential null return). Make sense ?
>>
>> Jerome
>>
>> On Sep 22, 2009, at 16:02, Lloyd Chambers <Lloyd.Chambers_at_Sun.COM
>> <mailto:Lloyd.Chambers_at_Sun.COM>> wrote:
>>
>>> I don't have an answer to that question, and I also do not like the
>>> dependency.
>>>
>>> The goal is to provide a method for the GUI to call to force the JMS
>>> broker to load:
>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=8990
>>>
>>> This is what has to be imported:
>>>
>>> import com.sun.enterprise.connectors.ConnectorRuntime;
>>> import com.sun.appserv.connectors.internal.api.ConnectorConstants;
>>> import com.sun.appserv.connectors.internal.api.ConnectorsUtil;
>>> import com.sun.enterprise.connectors.ConnectorRegistry;
>>>
>>>
>>>
>>> On Sep 22, 2009, at 3:56 PM, Snjezana Sevo-Zenzerovic wrote:
>>>
>>>> Note that the unwanted side-effect of this change will be that
>>>> connectors-runtime.jar will magically move from glassfish-jca
>>>> package (where it is supposed to be) into glassfish-common package
>>>> (where AMX jars are)...
>>>>
>>>> There is connectors-internal-api jar already in glassfish-common
>>>> package. Is there any way to reshuffle things and have the
>>>> dependency on that jar?
>>>>
>>>> Thanks,
>>>>
>>>> Snjezana
>>>>
>>>>
>>>> Lloyd Chambers wrote:
>>>>> This change is to support a new method loadJMSBroker(), per
>>>>> request of the GUI team.
>>>>>
>>>>>
>>>>> llcMule-2:amx-ext-impl llc$ svn diff pom.xml
>>>>> Index: pom.xml
>>>>> ===================================================================
>>>>> --- pom.xml (revision 31713)
>>>>> +++ pom.xml (working copy)
>>>>> @@ -106,5 +106,11 @@
>>>>> <version>3.0.0-b004</version>
>>>>> </dependency>
>>>>>
>>>>> + <dependency>
>>>>> + <groupId>org.glassfish.connectors</groupId>
>>>>> + <artifactId>connectors-runtime</artifactId>
>>>>> + <version>${project.version}</version>
>>>>> + </dependency>
>>>>> +
>>>>> </dependencies>
>>>>> </project>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>> <mailto:dev-help_at_glassfish.dev.java.net>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>> <mailto:dev-help_at_glassfish.dev.java.net>
>>>>
>>>
>>> Lloyd Chambers
>>> lloyd.chambers_at_sun.com <mailto:lloyd.chambers_at_sun.com>
>>> GlassFish Team
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>> <mailto:dev-help_at_glassfish.dev.java.net>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> <mailto:dev-unsubscribe_at_glassfish.dev.java.net>
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>> <mailto:dev-help_at_glassfish.dev.java.net>
>>
>
> Lloyd Chambers
> lloyd.chambers_at_sun.com <mailto:lloyd.chambers_at_sun.com>
> GlassFish Team
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>