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.
>
>
> - 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
>