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
[email protected] <mailto:[email protected]>
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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
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
<[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>>
>>
>> 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
>>
