Lloyd Chambers wrote:
> Not true.
Which part?
I do see that if I don't inject the corresponding @Configured object, I do not
get the notifications :(.
Regards,
-marina
>
> See org.glassfish.admin.mbeanserver.UnprocessedConfigListener
>
> Lloyd
>
> On Jul 28, 2009, at 3:25 PM, Marina Vatkina wrote:
>
>> 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?
>>
>>
>> That's what Jerome told me some time back.
>>
>>> 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.
>>
>>
>> IIUC it gets only its own events, so that Unprocessed events mean
>> server restart is required, not that they are somebody elses. But I
>> might be wrong...
>>
>> On the other hand, if it is the case, a single class can't listen to
>> changes of 2 different @Configured objects...
>>
>> 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
>>
>
> 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
>