Yes, an @Contract / @Service with a public method.
Lloyd
On Sep 24, 2009, at 10:30 AM, Jason Lee wrote:
> Thanks. Where did we come down on this? IIRC, Satish is to expose
> a public method on the @Service, which we'll call from the console?
>
> On Sep 24, 2009, at 12:27 PM, Lloyd Chambers wrote:
>
>> Agreed.
>>
>> I would really prefer not to have any more dependencies; strictly
>> speaking such MBeans belong in their respective modules, but that's
>> a chicken-and-egg thing for bootstrapping something.
>>
>> Satish, please let me know when the @Contract support is
>> available. I assume the interface will be in glassfish-api.
>>
>> Lloyd
>>
>> On Sep 23, 2009, at 9:42 AM, Jerome Dochez wrote:
>>
>>> sounds good to me but AMX should interact with it through a
>>> contract. One of the point we are trying to resolve is no not have
>>> AMX depends on a module like the jms module. So we need an
>>> "intermediate" contract that binds AM\X to jms module.
>>>
>>> you can keep the MQInitializer contract I was proposing below, and
>>> just have your JmsProviderLifecycle implement it.
>>>
>>> jerome
>>>
>>> On Sep 23, 2009, at 7:08 AM, Satish Kumar wrote:
>>>
>>>> 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> 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
>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>> For additional commands, e-mail: dev-
>>>>>>>> help_at_glassfish.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>> Lloyd Chambers
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>> Lloyd Chambers
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> Lloyd Chambers
>> 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
>>
>
> Jason Lee
> Senior Java Developer
> GlassFish Administration Console
>
> Sun Microsystems, Inc.
> Phone x31197/+1 405-343-1964
> Email jasondlee_at_sun.com
> Blog http://blogs.sun.com/jasondlee
> Blog http://blogs.steeplesoft.com
>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team