Jerome Dochez wrote:
>
> On Jul 28, 2009, at 3:00 PM, Tim Quinn wrote:
>
>> Marina Vatkina wrote:
>>
>>> Hi Tim,
>>>
>>> The problem is different - because the current version (that you
>>> have in your ws) does not inject TransactionService,
>>> JavaEETransactionManagerSimplified doesn't get notifications about
>>> changes to it on the server side.
>>>
>>> Let me see if moving the the listener code out to a separate class
>>> solves the problem...
>>
>> Maybe I've learned something important here.
>>
>> Does a class need to inject a @Configured object in order to receive
>> changes for it?
>> I thought just implementing ConfigListener was sufficient, and then
>> the "changed" method could sift through the events to find ones of
>> interest, whether the config object of interest was injected or not.
>
> nope you only get notified for the @Configured object you were injected
> with...
> and it should work to listen to more than one object, not need to have
> 2 listeners.
Yes, I came to this conclusion empirically :).
I solved the problem by creating a separate config listener impl and instantiate
it via habitat when TimerService is up.
thanks,
-marina
>
>>
>>
>> - Tim
>>
>>>
>>> Jerome,
>>>
>>> Can the same listener listen to several even types (I need
>>> monitoring level as well) or do I need to have 2 separate classes?
>>>
>>> thanks,
>>> -marina
>>>
>>> Tim Quinn wrote:
>>>
>>>>
>>>>
>>>> Marina Vatkina wrote:
>>>>
>>>>> I don't know what is available in ACC, what not and why :(,
>>>>
>>>>
>>>> It's supposed to be relatively simple - the ACC does not have
>>>> access to the server's configuration. TransactionService is
>>>> recorded in domain.xml - that is, in the server's config - so the
>>>> ACC will not know about it and therefore it cannot be injected.
>>>> The same is true for all domain.xml-resident configuration
>>>> information.
>>>>
>>>> There's some logic in JavaEETransactionManagerSimplified - at least
>>>> the version in my workspace - which does not inject
>>>> TransactionService but asks the habitat to look it up explicitly
>>>> (around line 200). The comments imply that the logic is designed
>>>> to work differently on the server vs. the client. And my workspace
>>>> copy of the class does not inject TransactionService.
>>>>
>>>> What would the JavaEETransactionManagerSimplified do - on the
>>>> client - with this config information?
>>>>
>>>>
>>>> - Tim
>>>>
>>>>> but [1] is the stack trace from the failed injection in ACC.
>>>>>
>>>>> Is it possible to somehow identify a service for a specific
>>>>> injection type?
>>>>>
>>>>> thanks,
>>>>> -marina
>>>>>
>>>>> [1]:
>>>>> [exec] INFO: Cannot inject private
>>>>> com.sun.enterprise.config.serverbeans.TransactionService com .sun
>>>>> .enterprise
>>>>> .transaction.JavaEETransactionManagerSimplified.txnService in
>>>>> componentcom .sun
>>>>> .enterprise.transaction.JavaEETransactionManagerSimplified_at_f3552f
>>>>> [exec] org.jvnet.hk2.component.UnsatisfiedDepedencyException:
>>>>> Unsatisfied dependency exception : private
>>>>> com.sun.enterprise.config.serverbeans.TransactionService com .sun
>>>>> .enterprise .transaction.JavaEETransactionManagerSimplified.txnService
>>>>> [exec] at org .jvnet
>>>>> .hk2.component.InjectionManager.inject(InjectionManager.java:102)
>>>>> [exec] at com
>>>>> .sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java: 170)
>>>>> [exec] at com.sun.hk2.component.ConstructorWomb
>>>>> $1.run(ConstructorWomb.java:89)
>>>>> [exec] at
>>>>> java.security.AccessController.doPrivileged(Native Method)
>>>>> [exec] at com .sun
>>>>> .hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:86)
>>>>> [exec] at
>>>>> com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java: 77)
>>>>> [exec] at com .sun
>>>>> .hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58)
>>>>> [exec] at
>>>>> com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107)
>>>>> [exec] at com .sun .hk2
>>>>> .component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java: 60)
>>>>> [exec] at
>>>>> org.jvnet.hk2.component.Habitat.getByContract(Habitat.java:588)
>>>>> [exec] at com .sun .enterprise .transaction
>>>>> .TransactionInvocationHandler
>>>>> .init(TransactionInvocationHandler.java:72)
>>>>> [exec] at com .sun .enterprise .transaction
>>>>> .TransactionInvocationHandler
>>>>> .afterPreInvoke(TransactionInvocationHandler.java:83)
>>>>> [exec] at org .glassfish .api .invocation
>>>>> .InvocationManagerImpl.preInvoke(InvocationManagerImpl.java:148)
>>>>> [exec] at
>>>>> org.glassfish.appclient.client.acc.AppClientContainer $
>>>>> ClientMainClassSetting.getClientMainClass(AppClientContainer.java:
>>>>> 571)
>>>>> [exec] at org .glassfish .appclient .client
>>>>> .acc.AppClientContainer.getMainMethod(AppClientContainer.java:474)
>>>>> [exec] at org .glassfish .appclient .client .acc
>>>>> .AppClientContainer.completePreparation(AppClientContainer.java: 382)
>>>>> [exec] at org .glassfish .appclient
>>>>> .client.acc.AppClientContainer.prepare(AppClientContainer.java:305)
>>>>> [exec] at org .glassfish
>>>>> .appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:
>>>>> 262)
>>>>> [exec] at org .glassfish .appclient .client .acc .agent
>>>>> .AppClientContainerAgent.premain(AppClientContainerAgent.java:75)
>>>>> [exec] at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> [exec] at sun .reflect
>>>>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>> [exec] at sun .reflect .DelegatingMethodAccessorImpl
>>>>> .invoke(DelegatingMethodAccessorImpl.java:25)
>>>>> [exec] at java.lang.reflect.Method.invoke(Method.java:597)
>>>>> [exec] at sun .instrument .InstrumentationImpl
>>>>> .loadClassAndStartAgent(InstrumentationImpl.java:323)
>>>>> [exec] at sun .instrument .InstrumentationImpl
>>>>> .loadClassAndCallPremain(InstrumentationImpl.java:338)
>>>>> [exec] Caused by:
>>>>> org.jvnet.hk2.component.UnsatisfiedDepedencyException: Unsatisfied
>>>>> dependency exception : private
>>>>> com.sun.enterprise.config.serverbeans.TransactionService com .sun
>>>>> .enterprise .transaction.JavaEETransactionManagerSimplified.txnService
>>>>> [exec] at org .jvnet
>>>>> .hk2.component.InjectionManager.inject(InjectionManager.java:97)
>>>>> [exec] ... 24 more
>>>>> [exec] Result: 1
>>>>>
>>>>>
>>>>> Marina Vatkina wrote:
>>>>>
>>>>>> Jerome, Ken, Tim,
>>>>>>
>>>>>> I know why TM is not getting events, but I don't know what to do
>>>>>> about it...
>>>>>>
>>>>>> For transaction-service events to be sent, the TransactionService
>>>>>> field need to be *injected* into TM.
>>>>>>
>>>>>> But(!) TransactionService can't be injected when executed in ACC
>>>>>> (at least this is what was happening back in April when I
>>>>>> switched from injection to habitat access):
>>>>>>
>>>>>> [exec] INFO: Cannot inject private
>>>>>> com.sun.enterprise.config.serverbeans.TransactionService com
>>>>>> .sun .enterprise
>>>>>> .transaction.JavaEETransactionManagerSimplified.txnService in
>>>>>> componentcom .sun
>>>>>> .enterprise.transaction.JavaEETransactionManagerSimplified_at_3a835d
>>>>>>
>>>>>> Tim, Ken, did it change since then?
>>>>>>
>>>>>> Are there any other options?
>>>>>>
>>>>>> thanks,
>>>>>> -marina
>>>>>>
>>>>>> Marina Vatkina wrote:
>>>>>>
>>>>>>> JavaEETransactionManagerSimplified doesn't get any
>>>>>>> TransactionService events (all of them would be change).
>>>>>>>
>>>>>>> To reproduce - deploy any app to start the TM, enable 'jta'
>>>>>>> logger to FINE, then do e.g.
>>>>>>>
>>>>>>> asadmin set server.transaction-service.retry-timeout-in- seconds=50
>>>>>>>
>>>>>>> (I didn't try admingui).
>>>>>>>
>>>>>>> If the change() method is called, you get 'Got
>>>>>>> TransactionService change event ==== ' append with the event
>>>>>>> name, the old and the new value log message.
>>>>>>>
>>>>>>> thanks,
>>>>>>> -marina
>>>>>>>
>>>>>>> Anissa Lam wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, i have filed bug
>>>>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=8815
>>>>>>>> Adding jvm option eg. -Djava.security.manager will not trigger
>>>>>>>> the server-restart-required status. Changing value of
>>>>>>>> existing jvm option does and behaves correctly.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> Anissa
>>>>>>>>
>>>>>>>>
>>>>>>>> Jerome Dochez wrote:
>>>>>>>>
>>>>>>>>> I don't remember changing anything but I will look at it. do
>>>>>>>>> you have a reproduceable case to speed things up.
>>>>>>>>>
>>>>>>>>> thx, jerome
>>>>>>>>> On Jul 24, 2009, at 5:03 PM, Lloyd Chambers wrote:
>>>>>>>>>
>>>>>>>>>> Anissa tells me she is not seeing restart required events.
>>>>>>>>>>
>>>>>>>>>> So yes, I think something was broken somewhere.
>>>>>>>>>>
>>>>>>>>>> Lloyd
>>>>>>>>>>
>>>>>>>>>> On Jul 24, 2009, at 4:57 PM, Marina Vatkina wrote:
>>>>>>>>>>
>>>>>>>>>>> Did something change recently? Tx manager does not get any
>>>>>>>>>>> notifications when the transaction-service element is
>>>>>>>>>>> changed. The value is correctly stored in the domain.xml.
>>>>>>>>>>>
>>>>>>>>>>> I call asadmin set after I see the message in the log that
>>>>>>>>>>> Tx manager had been initialized.
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>> -marina
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>