Perfect. I'll wait (semi) patiently. :)
On Sep 24, 2009, at 12:33 PM, Lloyd Chambers wrote:
> 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
>
>
>
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