deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nico Schlebusch <nicos...@gmail.com>
Subject Re: DeltaSpike Data - Custom PrePersistAuditListener and PreUpdateAuditListener
Date Fri, 06 Jan 2017 15:07:57 GMT
Hi John,

Issue raised - https://issues.apache.org/jira/browse/DELTASPIKE-1229

Kind regards,
Nico Schlebusch
nicoschl@gmail.com <mailto:nicoschl@gmail.com>


On 20/12/2016 23:13, Nico Schlebusch wrote:
> No problem, thanks for your help. I'll raise the issue in JIRA.
>
> Kind regards,
> Nico Schlebusch
> nicoschl@gmail.com <mailto:nicoschl@gmail.com>
>
>
> On 20/12/2016 23:11, John D. Ament wrote:
>> Gah shoot, sorry about that.  It won't work because its a package private
>> class, and the classloader will block it.
>>
>> I'll get something in to fix this, unfortunately it won't work until my
>> change is in.  Please do make sure to raise an issue in JIRA so I don't
>> lose track.  Thanks for checking it out.
>>
>> John
>>
>> On Tue, Dec 20, 2016 at 4:07 PM Nico Schlebusch<nicoschl@gmail.com>  wrote:
>>
>>> Hi John,
>>>
>>> Thanks for the suggestion on vetoing the TimestampsProvider, but there is
>>> a new problem with my approach or lack of understanding of Portable
>>> Extensions.
>>>
>>> I first created the portable extension inside my own package structure,
>>> but then the compiler fails to resolve TimestampsProvider because it is a
>>> package protected class. I then moved my extension into the same package
>>> (org.apache.deltaspike.data.impl.audit) as TimestampsProvider but then got
>>> this exception on deployment
>>>
>>> Caused by: java.lang.IllegalAccessError: tried to access class
>>> org.apache.deltaspike.data.impl.audit.PrincipalProvider from class
>>> org.apache.deltaspike.data.impl.audit.VetoDeltaSpikeAuditProvidersExtension
>>>          at
>>> org.apache.deltaspike.data.impl.audit.VetoDeltaSpikeAuditProvidersExtension.rejectPrincipalProvider(VetoDeltaSpikeAuditProvidersExtension.java:43)
>>>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>          at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>          at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>          at java.lang.reflect.Method.invoke(Method.java:498)
>>>          at
>>> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
>>>
>>> I read somewhere that happens when the classes aren't loaded with the same
>>> classloader.
>>>
>>> Any other ideas on how to veto the TimestampsProvider?
>>>
>>>
>>> Kind regards,
>>> Nico Schlebusch
>>> nicoschl@gmail.com
>>>
>>>
>>> On 20/12/2016 17:23, John D. Ament wrote:
>>>
>>> Ok, that makes sense.  I wanted to verify your behavior, which means
>>> alternative makes no sense here.
>>>
>>> So with that said, what I'm thinking is that you can forcibly veto the
>>> class in a portable extension to disable its execution.  It would be as
>>> simple as
>>>
>>>      public void rejectDefaultClass(@Observes
>>> ProcessAnnotatedType<TimestampsProvider> pat) {
>>>          pat.veto();
>>>      }
>>>
>>>
>>> John
>>>
>>> On Tue, Dec 20, 2016 at 9:54 AM Nico Schlebusch<nicoschl@gmail.com>
>>> wrote:
>>>
>>> John,
>>>
>>> That loop executes the number of times there are implementations of the
>>> PrePersistAuditListener. When I have my own implementation deployed it
>>> executes 3 times. The PrincipalProvider, my custom implementation
>>> (UTCDateTimeAuditProvider) and then TimestampsProvider are executed in
>>> that order.
>>>
>>> Kind regards,
>>> Nico Schlebusch
>>> nicoschl@gmail.com  <mailto:nicoschl@gmail.com>
>>>
>>>
>>> On 20/12/2016 16:33, John D. Ament wrote:
>>>> Nico,
>>>>
>>>> There's a for loop here
>>>>
>>> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/audit/AuditEntityListener.java#L38
>>>> How many times does this for loop execute?
>>>>
>>>> John
>>>>
>>>> On Tue, Dec 20, 2016 at 9:23 AM Nico Schlebusch<nicoschl@gmail.com>
>>> wrote:
>>>>> Hi John,
>>>>>
>>>>> Thanks for the answer.
>>>>>
>>>>> The AuditEntityListener is called once from my debugging sessions.
>>>>>
>>>>> I'll definitely raise a feature request, it might just not be in the
>>> next
>>>>> 2 weeks. Would the feature request be to take @Alternative beans into
>>>>> considerations when looking up the beans that implements the 2
>>> interfaces,
>>>>> PrePersistAuditListener & PreUpdateAuditListener? Meaning that lines
>>> 40-41
>>>>> and 53-54 from the link below, need to filter out the @Default beans
>>> when
>>>>> an @Alternative is available? Or should I phrase it differently?
>>>>>
>>>>> Kind regards,
>>>>> Nico Schlebusch
>>>>> nicoschl@gmail.com
>>>>>
>>>>>
>>>>> On 20/12/2016 15:56, John D. Ament wrote:
>>>>>
>>>>> Nico,
>>>>>
>>>>> Seems the logic in DeltaSpike is to loop through the beans.  Can you
>>> check
>>>>> if you're seeing this loop is called multiple times?
>>>>>
>>> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/audit/AuditEntityListener.java
>>>>> Anyways, would be good to have this support direct in deltaspike.  Mind
>>>>> raising a feature request?
>>>>> https://issues.apache.org/jira/browse/DELTASPIKE
>>>>>
>>>>> John
>>>>>
>
>



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message