Re: 2.0.1-SNAPSHOT - module buile not possible - org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT was not found

[Romain Manni-Bucau]

Hi Thomas,

Did you build the project before running your command (mvn install
-DskipTests -T1C)?
Which maven version do you use, 3.9?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 5 avr. 2024 à 09:56, Thomas Frühbeck  a
écrit :

> Hi,
>
> since move do 2.0.1-SNAPSHOT it is not possible to build modules:
> (commit 48fbfea1ef93da80f2e8b620808332be4cef66f4)
>
>  The following artifacts could not be resolved:
> org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT (absent)
>
> I don't know how to build the pom locally :-/
>
>
> Your branch is up to date with 'origin/master'.
> ~/workspace-ds/deltaspike/deltaspike> mvn dependency:tree -pl
> modules/data/impl/
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.apache.deltaspike.modules:deltaspike-data-module-impl
> >--
> [INFO] Building Apache DeltaSpike Data-Module Impl 2.0.1-SNAPSHOT
> [INFO]   from pom.xml
> [INFO] [ jar
> ]-
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  1.087 s
> [INFO] Finished at: 2024-04-05T09:51:17+02:00
> [INFO]
> 
> [ERROR] Failed to execute goal on project deltaspike-data-module-impl:
> Could not resolve dependencies for project
>
> org.apache.deltaspike.modules:deltaspike-data-module-impl:jar:2.0.1-SNAPSHOT:
> Failed to collect dependencies at
>
> org.apache.deltaspike.modules:deltaspike-data-module-api:jar:2.0.1-SNAPSHOT:
> Failed to read artifact descriptor for
>
> org.apache.deltaspike.modules:deltaspike-data-module-api:jar:2.0.1-SNAPSHOT:
> The following artifacts could not be resolved:
> org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT (absent):
> org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT was not found in
> https://repository.apache.org/snapshots/ during a previous attempt. This
> failure was cached in the local repository and resolution is not
> reattempted until the update interval of apache-snapshot-repository has
> elapsed or updates are forced -> [Help 1]
>
>
> [ERROR] Failed to execute goal on project deltaspike-data-module-api: Could
> not resolve dependencies for project
>
> org.apache.deltaspike.modules:deltaspike-data-module-api:jar:2.0.1-SNAPSHOT:
> Failed to collect dependencies at
> org.apache.deltaspike.core:deltaspike-core-api:jar:2.0.1-SNAPSHOT: Failed
> to read artifact descriptor for
> org.apache.deltaspike.core:deltaspike-core-api:jar:2.0.1-SNAPSHOT: The
> following artifacts could not be resolved:
> org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT (absent): Could not
> find artifact org.apache.deltaspike:deltaspike:pom:2.0.1-SNAPSHOT in
> apache-snapshot-repository (https://repository.apache.org/snapshots/)
>

Re: [VOTE] Release Apache DeltaSpike-2.0.0

[Romain Manni-Bucau]

+1

Le ven. 29 mars 2024 à 18:55, John D. Ament  a
écrit :

> +1 LGTM
>
> Though I always question when release notes mention things that are Won't
> Do as being included in them, not a problem for the release.
>
> On Fri, Mar 29, 2024 at 10:45 AM Mark Struberg 
> wrote:
>
> > Good afternoon!
> >
> > I'd like to call a VOTE on releasing Apache DeltaSpike-2.0.0
> >
> > The list of fixed tickets can be found in the release notes
> >
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/readme/ReleaseNotes-2.0.0.txt
> >
> > This is the first version to natively target JakartaEE-9 and the
> jakarta.*
> > namespace.
> >
> > The staging repo is available under:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1060/
> >
> > The source release zip can be found here
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1060/org/apache/deltaspike/deltaspike/2.0.0/
> >
> > the sha512 is
> >
> >
> 06a462cd3e66457cc35bc88e8ec0f63f4560fa4bdf4d91cb0983e07001c05fbf4fa7d50d73310a9e52fb420824256e69bf373a1d03750858645f5e83120f5d1e
> >
> > Please VOTE
> >
> > [+1] let's ship it
> > [+0] don't care
> > [-1] stop, there is a ${showstopper}
> >
> > The VOTE is open for 72h
> >
> >
> >
> > txs and LieGrue,
> > strub
> >
>

Re: Release 2.0.0-M1?

[Romain Manni-Bucau]

Le jeu. 21 mars 2024 à 12:24, Thomas Andraschko 
a écrit :

> why is not needed for batchee? ->
> https://github.com/apache/geronimo-batchee/blob/master/pom.xml#L66


Cause it was before CDI 2.0 and SeContainer, now it is there we don't have
a case for deltaspike anymore in BatchEE and we already have the compat.
We just kept it in pre-jakarta release for backward compat but since next
release will break it anyway we'll just drop it normally.


>
>
> Im not really sure about doing a "real" release as we removed so many code
> and features, i'm not sure if we removed to much or miss something.
> Therefore i thought about a M1 or RC1 first.
>

Adding is always ok compared to dropping after.
Anyway, as mentionned M, alpha, beta, RC don't really enable to get user
feedback so skipping it since we are not in a bad shape is likely worth it
for the project.

Indeed just my 2cts and not a veto or anything close at all.


>
> Am Do., 21. März 2024 um 12:04 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Hi Thomas,
> >
> > This is not needed for BatchEE but ultimately I guess we can do a 2.0.0,
> > nothing crazy is really expected after anyway and we can do 2.0.1 if
> needed
> > no? (milestones and alpha are always dead numbers from my perspective so
> it
> > is either ready or it is not - this philosophy makes things simpler after
> > IMHO).
> >
> > Best,
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le jeu. 21 mars 2024 à 09:45, Thomas Andraschko <
> > andraschko.tho...@gmail.com>
> > a écrit :
> >
> > > Hi,
> > >
> > > short: We need a DS release, to release BatchEE, to release TomEE M1.
> > >
> > > In general i think we are ready for a M1, our tests are running,
> > > OWB+Weld+Wildfly builds are green. TomEE and Payara are almost green,
> see
> > > the other mail.
> > >
> > > WDYT?
> > >
> > > Best regards,
> > > Thomas
> > >
> >
>

Re: Release 2.0.0-M1?

[Romain Manni-Bucau]

Hi Thomas,

This is not needed for BatchEE but ultimately I guess we can do a 2.0.0,
nothing crazy is really expected after anyway and we can do 2.0.1 if needed
no? (milestones and alpha are always dead numbers from my perspective so it
is either ready or it is not - this philosophy makes things simpler after
IMHO).

Best,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 21 mars 2024 à 09:45, Thomas Andraschko 
a écrit :

> Hi,
>
> short: We need a DS release, to release BatchEE, to release TomEE M1.
>
> In general i think we are ready for a M1, our tests are running,
> OWB+Weld+Wildfly builds are green. TomEE and Payara are almost green, see
> the other mail.
>
> WDYT?
>
> Best regards,
> Thomas
>

Re: DS-2.0.0 - Wildfly - BeanMangerDelegate - subdeployment reverse bean visibilty issue

[Romain Manni-Bucau]

+1 to explicitly set the property in the profile since it has some negative
perf impacts and the system property can not be sufficient - until we also
check the actual env.

Can also mean we lookup the beans less often at runtime and more in
postconstructs or just use plain injects (don't recall why it was not the
case).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 18 mars 2024 à 09:21, Thomas Andraschko 
a écrit :

> Can we just set this property based on the profiles for our tests?
> This is probably also required for payara users, we have to add it to the
> docs then of course.
>
> Am So., 10. März 2024 um 14:49 Uhr schrieb Thomas Frühbeck <
> t.fruehb...@gmail.com>:
>
> > We have already discussed the problem of interceptorLookup for
> PartialBean
> > on Wildfly.
> > IMHO due to subdeployment CL-visibilty issues (not flat!) the
> interceptors
> > in jar A are not visible in jar DS-partial-bean-impl.
> >
> > A possible solution for this can be:
> > BeanMangerProvider#getBeanManager(): extend decision on lookup strategy
> > like
> > private static boolean useDelegateLookup()
> > {
> > return CoreBaseConfig.BeanManagerIntegration.DELEGATE_LOOKUP
> > && System.getProperty("jboss.server.name") == null;
> > }
> >
> > Then all tests in partial-bean-impl -P wildfly-build-managed run
> > successfully!
> >
> > Another issue that could be resolved this way: TransactionStrategy lookup
> > in data-impl:
> > Instead of @Priority workaround
> >   - activate ContainerMangedTxStrategy in beans.xml
> >   - and change Injection of TransactionStrategy in
> TransactionalQueryRunner
> > like:
> > protected Object executeTransactional(final QueryBuilder builder,
> final
> > CdiQueryInvocationContext context)
> > {
> > TransactionStrategy strategy =
> > BeanProvider.getContextualReference(TransactionStrategy.class);
> >
> > will also work fine!
> >
> > Just to show the massive impact of the identified (supposed?) bug in
> > Wildfly subdeployment class visibility.
> >
> > First step: your feedback on the proposed (temporary?) fix on
> > abovementioned change in BeanManagerLookup
> > :-/
> >
>

Re: DS-2.0.0 - PartialBean - Proxy doesn't call delegate?

[Romain Manni-Bucau]

Yes, this is not opposed to the spec, just totally unusable when
implemented this way and the "normal" behavior is not opposed to the spec
neither (welcome in CDI land ;)).
Question is: do we hack tests for them to pass and still break in real apps
or do we ask them to finally fix their appbut they didnt in 15 years so
no big hope weld become more usable from our point of view.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 11 mars 2024 à 21:10, Thomas Andraschko 
a écrit :

> Cant open the link :/
>
> Thomas Frühbeck  schrieb am Mo., 11. März 2024,
> 21:03:
>
> > Now it seems fixed: Wildfly's BDAs are isolated, no visibility inside DS
> of
> > outside Beans/Interceptors/...
> > Details see: https://issues.redhat.com/browse/WFLY-19111
> > Kinda interresting read - no spec violation by raw words - but I don't
> > quite get the point :-/
> >
> > Am So., 10. März 2024 um 15:20 Uhr schrieb Thomas Frühbeck <
> > t.fruehb...@gmail.com>:
> >
> > > Now issue created successfully:
> > > https://issues.redhat.com/browse/WFLY-19111
> > >
> > > Am Sa., 9. März 2024 um 17:18 Uhr schrieb Thomas Frühbeck <
> > > t.fruehb...@gmail.com>:
> > >
> > >> Follow-Up: I think I successfully created a 2-module war project
> > >> reproducing the problem.
> > >> Tried to create a bug report on Wildfly - permission denied
> > >> :-/
> > >>
> > >> Am Sa., 9. März 2024 um 13:29 Uhr schrieb Romain Manni-Bucau <
> > >> rmannibu...@gmail.com>:
> > >>
> > >>> We can but wonder if it does not depend on wildfly version too but
> > >>> ultimagely we could detect it is wildfly and not capture the same BM.
> > >>> For standalone case it misses a web-inf/classes global BM so back to
> > the
> > >>> BDA issue.
> > >>> By reflection you can always lookup the right one using CDI impl -
> > >>> forcing
> > >>> caller class directly - but not sure it is good.
> > >>>
> > >>>
> > >>>
> >
>

Re: DS-2.0.0 - PartialBean - Proxy doesn't call delegate?

[Romain Manni-Bucau]

We can but wonder if it does not depend on wildfly version too but
ultimagely we could detect it is wildfly and not capture the same BM.
For standalone case it misses a web-inf/classes global BM so back to the
BDA issue.
By reflection you can always lookup the right one using CDI impl - forcing
caller class directly - but not sure it is good.

Le sam. 9 mars 2024 à 13:15, Thomas Frühbeck  a
écrit :

> One desperate step further and success?!?
>
> added apache-deltaspike.properties: deltaspike.bean-manager.delegate_lookup
> = false
> Now all tests pass in partial-bean.impl for wildfly-build-managed!
> (But then the Weld-only tests fail, reason to be identified :-/
>
> The difference I understand is to use the BeanManager passed
> to @AfterBeanDiscovery instead of CDI.current()
>
> Any ideas?
> Useful approach?
> Add a property for Wildfly to handle this?
>
>
> Am Fr., 8. März 2024 um 20:49 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Hmm, not sure I got it all but weld uses BDA isolation - no link to
> > classloaders, linked to physical jars/folders even in the same
> classloader.
> > The web-inf/classes can also see more than the web-inf/lib/x.jar due to
> > that - but it is a spec abuse AFAIK.
> > This is a blurry line in the CDI spec where vendors never agreed upon.
> >
> > I guess we can just detect it is weld and fallback on multiple captured
> bm
> > (jndi, provider one, CDI.current()) but it stays very fragile.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 8 mars 2024 à 19:34, Thomas Frühbeck  a
> > écrit :
> >
> > > Follow-Up: when designing Weld-only test I had missed a detail :-/
> > > Now following Weld-only test works perfectly fine!
> > >
> > > I desingned a bm#interceptorLookup on an injected BM in the arquillian
> > > test: works fine!
> > >
> > > The interceptor resolution inside DS by injected(!)
> > > DeltaSpikeProxyInterceptorLookup fails!
> > >
> > > So it seems that finally the reason may be the deployment isolation in
> > > Wildfly?!
> > >
> > > According docs web-archives should have flat CL, so I see no reason for
> > > isolation, I could not find any related configuration :-/
> > >
> > > I designed a simple 2-module web-app to simulate "reverse-visibility"
> > > issue: no problem detected!!
> > >
> > > Maybe the problem is related to the time, when
> > BeanManagerProviderExtension
> > > is fired - due to concurrent CL?
> > > I will try to simulate, but anyway: the problem seems to be
> substantial.
> > >
> > > How to proceed?
> > > Suggestions much appreciated!
> > >
> > > Simple Weld-only test:
> > > weld = new Weld().disableDiscovery()
> > > .addExtension(new BeanManagerProvider())
> > > .addExtension(new PartialBeanBindingExtension())
> > > .addInterceptor(CustomInterceptorImpl.class)
> > > .addPackages(CustomInterceptor.class, PartialBean.class,
> > > DeltaSpikeProxyInvocationHandler.class)
> > > .addBeanClass(PartialBean.class);
> > > container = weld.initialize();
> > > beanManager = container.getBeanManager();
> > > deltaSpikeProxyInterceptorLookup =
> > >
> > >
> >
> BeanProvider.getContextualReference(DeltaSpikeProxyInterceptorLookup.class);
> > >
> > > PartialBean partialBean =
> > > BeanProvider.getContextualReference(PartialBean.class);
> > > List> interceptorListBm =
> > > beanManager.resolveInterceptors(InterceptionType.AROUND_INVOKE, new
> > > AnnotationLiteral() {});
> > > Assert.assertFalse(interceptorListBm.isEmpty());
> > >
> > > List> interceptorList =
> > > deltaSpikeProxyInterceptorLookup.lookup(partialBean,
> > > PartialBean.class.getMethod("getResult"));
> > > Assert.assertFalse(interceptorList.isEmpty());
> > >
> > >
> > >
> > > Am Di., 5. März 2024 um 21:46 Uhr schrieb Romain Manni-Bucau <
> > > rmannibu...@gmail.com>:
> > >
> > > > Not sure what does weld in standalone mode but there JNDI is
> undefined.
> > > > That said it is still a change in behavior so a regression.
> > > > Anyone spotted that in the spec or is it a new BDA interpretation of
> > > weld?
> > > >
> > > > Fact that the behavior is broken in wildfly and broken in standalone
> > > > compared to old version is fishy, means we should use the BM only in
> > > > extension somehow which is just not compatible with most CDI code so
> > I'm
> > > > quite hesitant to modify DS where Weld is likely the culprit, wdyt?
> > > >
> > > >
> > > >
> > >
> >
>

Re: DS-2.0.0 - PartialBean - Proxy doesn't call delegate?

[Romain Manni-Bucau]

Hmm, not sure I got it all but weld uses BDA isolation - no link to
classloaders, linked to physical jars/folders even in the same classloader.
The web-inf/classes can also see more than the web-inf/lib/x.jar due to
that - but it is a spec abuse AFAIK.
This is a blurry line in the CDI spec where vendors never agreed upon.

I guess we can just detect it is weld and fallback on multiple captured bm
(jndi, provider one, CDI.current()) but it stays very fragile.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 8 mars 2024 à 19:34, Thomas Frühbeck  a
écrit :

> Follow-Up: when designing Weld-only test I had missed a detail :-/
> Now following Weld-only test works perfectly fine!
>
> I desingned a bm#interceptorLookup on an injected BM in the arquillian
> test: works fine!
>
> The interceptor resolution inside DS by injected(!)
> DeltaSpikeProxyInterceptorLookup fails!
>
> So it seems that finally the reason may be the deployment isolation in
> Wildfly?!
>
> According docs web-archives should have flat CL, so I see no reason for
> isolation, I could not find any related configuration :-/
>
> I designed a simple 2-module web-app to simulate "reverse-visibility"
> issue: no problem detected!!
>
> Maybe the problem is related to the time, when BeanManagerProviderExtension
> is fired - due to concurrent CL?
> I will try to simulate, but anyway: the problem seems to be substantial.
>
> How to proceed?
> Suggestions much appreciated!
>
> Simple Weld-only test:
> weld = new Weld().disableDiscovery()
> .addExtension(new BeanManagerProvider())
> .addExtension(new PartialBeanBindingExtension())
> .addInterceptor(CustomInterceptorImpl.class)
> .addPackages(CustomInterceptor.class, PartialBean.class,
> DeltaSpikeProxyInvocationHandler.class)
> .addBeanClass(PartialBean.class);
> container = weld.initialize();
> beanManager = container.getBeanManager();
> deltaSpikeProxyInterceptorLookup =
>
> BeanProvider.getContextualReference(DeltaSpikeProxyInterceptorLookup.class);
>
> PartialBean partialBean =
> BeanProvider.getContextualReference(PartialBean.class);
> List> interceptorListBm =
> beanManager.resolveInterceptors(InterceptionType.AROUND_INVOKE, new
> AnnotationLiteral() {});
> Assert.assertFalse(interceptorListBm.isEmpty());
>
> List> interceptorList =
> deltaSpikeProxyInterceptorLookup.lookup(partialBean,
> PartialBean.class.getMethod("getResult"));
> Assert.assertFalse(interceptorList.isEmpty());
>
>
>
> Am Di., 5. März 2024 um 21:46 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Not sure what does weld in standalone mode but there JNDI is undefined.
> > That said it is still a change in behavior so a regression.
> > Anyone spotted that in the spec or is it a new BDA interpretation of
> weld?
> >
> > Fact that the behavior is broken in wildfly and broken in standalone
> > compared to old version is fishy, means we should use the BM only in
> > extension somehow which is just not compatible with most CDI code so I'm
> > quite hesitant to modify DS where Weld is likely the culprit, wdyt?
> >
> >
> >
>

Re: DS-2.0.0 - PartialBean - Proxy doesn't call delegate?

[Romain Manni-Bucau]

Not sure what does weld in standalone mode but there JNDI is undefined.
That said it is still a change in behavior so a regression.
Anyone spotted that in the spec or is it a new BDA interpretation of weld?

Fact that the behavior is broken in wildfly and broken in standalone
compared to old version is fishy, means we should use the BM only in
extension somehow which is just not compatible with most CDI code so I'm
quite hesitant to modify DS where Weld is likely the culprit, wdyt?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 5 mars 2024 à 21:18, Thomas Frühbeck  a
écrit :

> Ad "initial context lookup": I made a Weld-only test (no EE, no
> InitialContext), which showed the same behavior.
> CDI.current in DS-core is different to CDI.current in
> MethodLevelInterceptorTest run by JUnit.
>
> Am Di., 5. März 2024 um 20:18 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > This is not related to interceptors, this is related to all single
> > deltaspike module from core (BeanManagerProvider) to Data or JSF ones
> > (mainly cause all modules rely on this provider).
> > So overall @Priority does not solve the issue.
> > What is weird is that weld/wildfly changed the behavior of CDI.current to
> > no more align initial context lookup and CDI.current which looks like a
> big
> > bug to me.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 5 mars 2024 à 20:13, Thomas Frühbeck  a
> > écrit :
> >
> > > Everything reverted, reason once again: Priority!
> > >
> > > DeltaSpikeProxyInterceptorLookup#resolveInterceptors fails because it
> > has a
> > > different BeanManager context!
> > > Will this mean, that all DS interceptor-related logic now
> > needs/requires(!)
> > > Priority annotation?
> > > PR sent.
> > >
> > > Am Sa., 2. März 2024 um 17:44 Uhr schrieb Thomas Frühbeck <
> > > t.fruehb...@gmail.com>:
> > >
> > > > I built a Weld-only test for Partial-Bean-Interceptor.
> > > >
> > > >>
> > > >>
> > >
> >
>

Re: DS-2.0.0 - PartialBean - Proxy doesn't call delegate?

[Romain Manni-Bucau]

This is not related to interceptors, this is related to all single
deltaspike module from core (BeanManagerProvider) to Data or JSF ones
(mainly cause all modules rely on this provider).
So overall @Priority does not solve the issue.
What is weird is that weld/wildfly changed the behavior of CDI.current to
no more align initial context lookup and CDI.current which looks like a big
bug to me.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 5 mars 2024 à 20:13, Thomas Frühbeck  a
écrit :

> Everything reverted, reason once again: Priority!
>
> DeltaSpikeProxyInterceptorLookup#resolveInterceptors fails because it has a
> different BeanManager context!
> Will this mean, that all DS interceptor-related logic now needs/requires(!)
> Priority annotation?
> PR sent.
>
> Am Sa., 2. März 2024 um 17:44 Uhr schrieb Thomas Frühbeck <
> t.fruehb...@gmail.com>:
>
> > I built a Weld-only test for Partial-Bean-Interceptor.
> >
> >>
> >>
>

Re: DS-2.0.0 - PartialBean - Proxy doesn't call delegate?

[Romain Manni-Bucau]

Hi,

Not sure for all tests but it is the well known old issue that weld bean
manager is per jar and not global - in particular for alternatives and even
in a war -
so 
org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInterceptorLookup#resolveInterceptors
does not resolve interceptors using the DS-core BM instead of the war BM
for ex.
You can checkout this goodness
;): org.jboss.weld.AbstractCDI#getCallingClassName.

The game is to get the right bean manager, one way is to use
beanManager=(BeanManager)
new InitialContext().lookup("java:comp/BeanManager") and not use
BeanManagerProvider for example (or hide this lookup with a config in the
provider like the one we already have to wrongly use CDI.current() for
example (we must not do it everytime but we do today).

Not sure of the best fix since this part is already overly hacky and we
need to get back to CDI 1.0 hacks to fix it it seems.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le sam. 2 mars 2024 à 17:44, Thomas Frühbeck  a
écrit :

> I built a Weld-only test for Partial-Bean-Interceptor.
> AFAICS the DeltaSpikeBeanConfigurator#createWith is not invoked by Weld
> (anymore?)
>
> I sent a PR for this test to simplify backtracking.
> Does this help?
>
> Am Di., 27. Feb. 2024 um 16:47 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
> > I had a look on the partialbean-impl module and it fails with weld
> (payara
> > & wildfly-build-managed) but works fine on tomee:
> > the problem seems to be in DeltaSpikeProxyInvocationHandler as the
> > interceptors are empty.
> > it seems that DeltaSpikeProxyInterceptorLookup the right interceptor are
> > correctly extracted but
> > beanManager.resolveInterceptors(InterceptionType.AROUND_INVOKE,
> > interceptorBindings);
> > doesnt return the SimpleCacheInterceptor.
> >
> > maybe you can debug a bit more into weld or talk with them?
> >
> >
> >
>

Re: RFC: ArquillianTests - CDI 4.0 - bean-discovery-mode

[Romain Manni-Bucau]

Hmm, this is a big breaking change between v3 and v4 I missed, let's just
do it, thanks for clarifying.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 22 févr. 2024 à 11:59, Thomas Frühbeck  a
écrit :

> IMHO this is not a bug of Wildfly/Weld!
> Reading the CDI-4.0 spec Wildfly behaves exactly as it is described.
>
> Am Do., 22. Feb. 2024 um 11:24 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Maybe I get it wrong but if it is a bug in wildfly we should just get it
> > fixed then integrate the new version IMHO, not sure the point to change
> > everything on our side - which is valid from a spec standpoint - to hide
> > other bugs (we test the most used case IIRC).
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le jeu. 22 févr. 2024 à 10:48, Thomas Frühbeck  a
> > écrit :
> >
> > > My proposed change is restricted to arquillian tests only!
> > > I verified, that at least Wildfly-31 defnitely removes all "default"
> > beans
> > > on "" from beans.
> > > By setting "" we would have to rewrite _all_ our relevant test
> > > classes.
> > > The current tests relied on discovery-mode="all", what makes sense as
> > > arquillian itself is already heavily restricted.
> > > A use of trim means a redesign that IMHO does not really add to quality
> > > assurance on this level.
> > > Thomas
> > >
> > > Am Do., 22. Feb. 2024 um 08:42 Uhr schrieb Romain Manni-Bucau <
> > > rmannibu...@gmail.com>:
> > >
> > > > Hmm, it stays the default but not the beans.xml we recommend nor
> > provide
> > > so
> > > > not sure, trim should stay what is recommended in apps IMHO,
> annotated
> > > is a
> > > > broken mode by design so not sure it is good to use it in real CDI
> app.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le jeu. 22 févr. 2024 à 08:39, Thomas Andraschko <
> > > > andraschko.tho...@gmail.com> a écrit :
> > > >
> > > > > +1
> > > > >
> > > > > Thomas Frühbeck  schrieb am Do., 22. Feb.
> > 2024,
> > > > > 07:42:
> > > > >
> > > > > > The current CDI 4.0 spec has moved to default bean-discovery-mode
> > > > > > "annotated".
> > > > > >
> > > > > > All Arquillian tests - I have seen yet - are using Asset.Empty as
> > > > > > "beans.xml" which causes all tests to fail - at least on
> > > > Wildfly-31.0.0.
> > > > > > This seems to be in accordance to spec.
> > > > > >
> > > > > > I propose to replace all - yet unspecific usages of Asset.Empty
> > with
> > > > the
> > > > > > following default:
> > > > > > ArchiveUtils:
> > > > > > public static final Asset beansXmlAll = new
> StringAsset(" > > > > > bean-discovery-mode=\"all\"/>")
> > > > > >
> > > > > > Using this default beans.xml all Arquillian tests in
> > > "wildfly-managed"
> > > > > are
> > > > > > OK - at least in Deltaspike-Core.
> > > > > >
> > > > > > Please note, that usage of "" is here unwanted, as it
> makes
> > > all
> > > > > > default beans unavailable.
> > > > > > All test I have seen yet seem to rely heavily on the previous
> > default
> > > > > > discovery-mode="all"!
> > > > > >
> > > > > > Please comment.
> > > > > > Thomas
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: RFC: ArquillianTests - CDI 4.0 - bean-discovery-mode

[Romain Manni-Bucau]

Maybe I get it wrong but if it is a bug in wildfly we should just get it
fixed then integrate the new version IMHO, not sure the point to change
everything on our side - which is valid from a spec standpoint - to hide
other bugs (we test the most used case IIRC).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 22 févr. 2024 à 10:48, Thomas Frühbeck  a
écrit :

> My proposed change is restricted to arquillian tests only!
> I verified, that at least Wildfly-31 defnitely removes all "default" beans
> on "" from beans.
> By setting "" we would have to rewrite _all_ our relevant test
> classes.
> The current tests relied on discovery-mode="all", what makes sense as
> arquillian itself is already heavily restricted.
> A use of trim means a redesign that IMHO does not really add to quality
> assurance on this level.
> Thomas
>
> Am Do., 22. Feb. 2024 um 08:42 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Hmm, it stays the default but not the beans.xml we recommend nor provide
> so
> > not sure, trim should stay what is recommended in apps IMHO, annotated
> is a
> > broken mode by design so not sure it is good to use it in real CDI app.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le jeu. 22 févr. 2024 à 08:39, Thomas Andraschko <
> > andraschko.tho...@gmail.com> a écrit :
> >
> > > +1
> > >
> > > Thomas Frühbeck  schrieb am Do., 22. Feb. 2024,
> > > 07:42:
> > >
> > > > The current CDI 4.0 spec has moved to default bean-discovery-mode
> > > > "annotated".
> > > >
> > > > All Arquillian tests - I have seen yet - are using Asset.Empty as
> > > > "beans.xml" which causes all tests to fail - at least on
> > Wildfly-31.0.0.
> > > > This seems to be in accordance to spec.
> > > >
> > > > I propose to replace all - yet unspecific usages of Asset.Empty with
> > the
> > > > following default:
> > > > ArchiveUtils:
> > > > public static final Asset beansXmlAll = new StringAsset(" > > > bean-discovery-mode=\"all\"/>")
> > > >
> > > > Using this default beans.xml all Arquillian tests in
> "wildfly-managed"
> > > are
> > > > OK - at least in Deltaspike-Core.
> > > >
> > > > Please note, that usage of "" is here unwanted, as it makes
> all
> > > > default beans unavailable.
> > > > All test I have seen yet seem to rely heavily on the previous default
> > > > discovery-mode="all"!
> > > >
> > > > Please comment.
> > > > Thomas
> > > >
> > >
> >
>

Re: RFC: ArquillianTests - CDI 4.0 - bean-discovery-mode

[Romain Manni-Bucau]

Hmm, it stays the default but not the beans.xml we recommend nor provide so
not sure, trim should stay what is recommended in apps IMHO, annotated is a
broken mode by design so not sure it is good to use it in real CDI app.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 22 févr. 2024 à 08:39, Thomas Andraschko <
andraschko.tho...@gmail.com> a écrit :

> +1
>
> Thomas Frühbeck  schrieb am Do., 22. Feb. 2024,
> 07:42:
>
> > The current CDI 4.0 spec has moved to default bean-discovery-mode
> > "annotated".
> >
> > All Arquillian tests - I have seen yet - are using Asset.Empty as
> > "beans.xml" which causes all tests to fail - at least on Wildfly-31.0.0.
> > This seems to be in accordance to spec.
> >
> > I propose to replace all - yet unspecific usages of Asset.Empty with the
> > following default:
> > ArchiveUtils:
> > public static final Asset beansXmlAll = new StringAsset(" > bean-discovery-mode=\"all\"/>")
> >
> > Using this default beans.xml all Arquillian tests in "wildfly-managed"
> are
> > OK - at least in Deltaspike-Core.
> >
> > Please note, that usage of "" is here unwanted, as it makes all
> > default beans unavailable.
> > All test I have seen yet seem to rely heavily on the previous default
> > discovery-mode="all"!
> >
> > Please comment.
> > Thomas
> >
>

[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715964#comment-17715964
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1434:


[~vanta] EE always had been selected for its stability until they start 
breaking and the adoption decrease so yes they exist and try to migrate without 
having to do it every year cause it costs money.

To answer your timeline question: it is not about the timeline since ASF does 
not have any strong timeline, it is likely more about the investment you can do.

For example join the discussion about the pruning on the list and when there is 
an agreement, if you cover all mainstream servers (I guess payara, tomee, 
wildfly) for the IT then the release is 3 days (vote process) but has no real 
blocker nor challenge.

If you consider the project as a consommable and don't care about the OSS side 
I'm tempted to say you should migrate to something more commercial like quarkus 
(money helps to maintain software in real life ;)).

> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715794#comment-17715794
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1434:


> Releases are cheap! There is no rule saying that a project can't make several 
> major releases in a (short) period.

Not for end users when they need to change their code every year/month (maybe 
you are an exception), the EE and Microprofile mess prove it being very true 
for a lot of our user base.

> And then take your time to make any improvements on top for the next major 
> release.

Deleting will not happen *on top*, this is the main issue and why there is a 
discussion.

> IMO it would be better to make a release that just replaces "javax" with 
> "jakarta" of the current/latest javax version of a lib. There is no need of a 
> major version here. One could use even a Maven classifier.

I was for the classifier option to have an early access flavor but the breaking 
change in EE API limit this solution now and will not enable to run in any 
jakarta server so we have to do the big jump sadly and therefore the IT 
question which require some investment.

> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715768#comment-17715768
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1434:


[~mgrigorov] this can look accurate but in pactise you hide the most important 
points:
 * this is a breaking version so you have to ask yourself as a project 
maintainer what you want to break more to give some stability to users (if you 
don't it means you will do a pure conversion release then break with next 
major, likely worse),
 * javax -> jakarta is not only about renaming, EE broke itself just after the 
renaming (CDI API for ex) so this is not only a renaming thing to migrate, this 
is also why the bytecode manipulation often works but also fails regularly,
 * even following this rule you still hit the fact containers are not up to 
date or no more compatible so you still have IT work

> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715725#comment-17715725
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1434:


The main issue is migrating away from it means doing yourself part of it since 
there is no real alternative in CDI land (microprofile is insanely unstable and 
doesnt cover 60% of DS) so tempted to say it depends what you use. For your 
information there are discussions on what should be kept for v2 (jakarta) or 
not on the list. As usual it is easy to say to the OSS "do my job" but the idea 
is more "join and help" so you are both welcome to join the list and do PR to 
make it move faster.

> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715306#comment-17715306
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1434:


The harm would be to just deliver soemthing broken and imply people keep 
investing time in pure lost, we dont work like that. As of today arquillian is 
partially ready so question is the container coverage we want. I guess payara, 
tomee, maybe wildfly (less sure today). Feel free to help to uodate the setup 
Jeremy to make it move faster.

> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Jakarta EE / DeltaSpike 2.0 Status

[Romain Manni-Bucau]

Le ven. 7 avr. 2023 à 09:46, Mark Struberg  a
écrit :

> a) I'd rather keep the current names. Just because of backward compat and
> adoption. Maybe the names are not perfect, but they are rather fine. It
> should really be mostly a package renaming and be done
>

+1


>
> b.) @Romain, there is a HUGE difference between DeltaSpike @Transactional
> and javax.transaction.Transactional:
> We have a very clear rule when it comes to Exceptions. In DS, if an
> Exception appears we will do a rollback, otherwise we will do a commit.
> In javax/jakarta @Transactional only RuntimeExceptions and
> ApplicationExceptions with rollback=true will create a rollback, all other
> Exceptions will still cause a commit. This was 1:1 taken from EJB (which is
> imo also rather broken). Most people don't even don't realise that they
> might get a FileNotFoundException in the middle of their business code and
> STILL all the half done changes will be committed.
>
> Otoh if you have a RuntimeException in some nested Services ,A.fn() calls
> B.fn(), which is not catched when returning from the EJB 'Business Method'
> B.fn() the whole transaction will get marked as rollbackOnly(). Even if you
> would have catched this very Exception in A.fn(). That's another major pain.
>
> I wrote a lengthy blog post about it many moons ago:
>
> https://struberg.wordpress.com/2015/04/21/transaction-and-exception-handling-in-ejbs-and-javaee7-transactional/
>
> All this was the reason why we introduced the DeltaSpike @Transactional.
> It has a very clear semantic:
> On the very layer ('business method' invocation) where the transaction got
> opened we do the check. If there is any Excpetion thrown -> Rollback,
> otherwise -> Commit.
> Any subsequent nested calls into @Transactional business methods are
> completely transparent.
>
> You can also mix this with EJB and leverage any platform provided features
> if you use our TransactionStrategy which uses an injected UserTransaction
> to get the best of both worlds.
>
> DeltaSpike @Transactional is btw also used in projects which do not use
> our data module. Thus I'd leave everything in place. Please also think
> about the poor souls which just want to move from javax to jakarta
> *without* having such a deep knowledge about DeltaSpike as we do!
>

Exactly, so even if the behavior is not exactly the same than DS - it is
what happens with all specs for impl coming before - it is strictly
equivalent and you can *always* make it work as intended so there is really
no strong point to keep it nowdays except backward compatibility we will
not get anyway since we move to jakarta so it is time to clean up the room
IMHO.
If  we don't follow that philosophy we should probably reimplement CDI too,
see the point.


>
>
> LieGrue,
> strub
>
>
>
> > Am 04.04.2023 um 10:06 schrieb Romain Manni-Bucau  >:
> >
> > Hi,
> >
> > Do we have some visibility about the usage?
> > Think jpa/tx feature tend to disappear in new applications because JTA
> got
> > it (we like or not the design is another thing but feature is there
> > built-in now comared to when DS was created).
> > So for a new major we can aim at dropping it - keeping in 1.x.
> > About data module I guess the adoption is not that high even if module is
> > really "cool" - guess we miss the jaxrs bridge but we never got any
> request
> > about it - so not sure its future.
> > It can likely be the same for almost all core module which is now almost
> > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > things without added value in time for a new major).
> >
> > So overall I wouldnt aim at renaming but more pruning what is built in or
> > will be soon and make DS lighter now resources are very low and the need
> of
> > the project really less important than years ago.
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> andraschko.tho...@gmail.com>
> > a écrit :
> >
> >> JPA is also about reading the JPA XML descriptors and resolving
> >> EntityManagers, which is both heavily used in the Data module.
> >> So its currently much more than TX. 

Re: Jakarta EE / DeltaSpike 2.0 Status

[Romain Manni-Bucau]

Le mar. 4 avr. 2023 à 11:18, Thomas Andraschko 
a écrit :

> I think the most features and modules are just working fine - normal tests
> are running.
> Just container testing may find weird bugs.
> So its not about the effort of "reimplementing features" vs "dropping
> features", its all already there.
>

I don't get it, there are a few things to consider:

1. we are going major with jakarta so the entry point is >> the one we had
before, for ex, BeanProvider or all bean builders are built in now so why
duplicating?
2. I didn't reall speak about "reimplementing" anything but more about
making it user friendly, if you take deltaspike + the required underlying
container as of today, > 60% overlaps so as an user what should you use? It
is was more obvious if the choice is unique to write clean and portable
code than having iso alternatives in the IDE IMHO.
3. we'll don't maintain the workarounds we have in the code and as you
mention we need some real effort to ensure it is portable (which is not as
of today AFAIK due to last weld updates) so the point of resources is key
from my point of view

So overall converging to the project staff and end users it makes sense to
drop most of what got added to the spec (sometimes thanks to DS :)).


> Am Di., 4. Apr. 2023 um 10:44 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Le mar. 4 avr. 2023 à 10:22, Thomas Andraschko <
> > andraschko.tho...@gmail.com>
> > a écrit :
> >
> > > In theory we could remove TX (if all cases are handled by JTA) and move
> > the
> > > EntityManagerResolver + JPA descriptor parsing to Data itself.
> > >
> > > In general i think our goal should be to port the DS features, if still
> > not
> > > existing in EE10, to EE10. Not to remove everything not widely used.
> > > This allows users to migrate to EE10 with some adjustments.
> > >
> >
> > This assumes it is used but this is really unsure, stats we have
> (central)
> > are really about CI zone and major is our best chance to drop what is not
> > needed to focus our effort on what is actually used.
> > Indeed not a blocker but my 2cts would be to drop what we can to
> > potentially add it back if we get a lot of demand rather than the
> opposite
> > which means we'll keep dragging things to maintain almost nobody needs.
> >
> >
> > >
> > >
> > > Am Di., 4. Apr. 2023 um 10:06 Uhr schrieb Romain Manni-Bucau <
> > > rmannibu...@gmail.com>:
> > >
> > > > Hi,
> > > >
> > > > Do we have some visibility about the usage?
> > > > Think jpa/tx feature tend to disappear in new applications because
> JTA
> > > got
> > > > it (we like or not the design is another thing but feature is there
> > > > built-in now comared to when DS was created).
> > > > So for a new major we can aim at dropping it - keeping in 1.x.
> > > > About data module I guess the adoption is not that high even if
> module
> > is
> > > > really "cool" - guess we miss the jaxrs bridge but we never got any
> > > request
> > > > about it - so not sure its future.
> > > > It can likely be the same for almost all core module which is now
> > almost
> > > > standard in CDI or Microprofile/coming Jakarta (idea being to not
> bring
> > > > things without added value in time for a new major).
> > > >
> > > > So overall I wouldnt aim at renaming but more pruning what is built
> in
> > or
> > > > will be soon and make DS lighter now resources are very low and the
> > need
> > > of
> > > > the project really less important than years ago.
> > > >
> > > > Hope it makes sense.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> > > > andraschko.tho...@gmail.com>
> > > > a écrit :
> > > >
> > > > > JPA is also about r

Re: Jakarta EE / DeltaSpike 2.0 Status

[Romain Manni-Bucau]

Le mar. 4 avr. 2023 à 10:22, Thomas Andraschko 
a écrit :

> In theory we could remove TX (if all cases are handled by JTA) and move the
> EntityManagerResolver + JPA descriptor parsing to Data itself.
>
> In general i think our goal should be to port the DS features, if still not
> existing in EE10, to EE10. Not to remove everything not widely used.
> This allows users to migrate to EE10 with some adjustments.
>

This assumes it is used but this is really unsure, stats we have (central)
are really about CI zone and major is our best chance to drop what is not
needed to focus our effort on what is actually used.
Indeed not a blocker but my 2cts would be to drop what we can to
potentially add it back if we get a lot of demand rather than the opposite
which means we'll keep dragging things to maintain almost nobody needs.


>
>
> Am Di., 4. Apr. 2023 um 10:06 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Hi,
> >
> > Do we have some visibility about the usage?
> > Think jpa/tx feature tend to disappear in new applications because JTA
> got
> > it (we like or not the design is another thing but feature is there
> > built-in now comared to when DS was created).
> > So for a new major we can aim at dropping it - keeping in 1.x.
> > About data module I guess the adoption is not that high even if module is
> > really "cool" - guess we miss the jaxrs bridge but we never got any
> request
> > about it - so not sure its future.
> > It can likely be the same for almost all core module which is now almost
> > standard in CDI or Microprofile/coming Jakarta (idea being to not bring
> > things without added value in time for a new major).
> >
> > So overall I wouldnt aim at renaming but more pruning what is built in or
> > will be soon and make DS lighter now resources are very low and the need
> of
> > the project really less important than years ago.
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 4 avr. 2023 à 09:57, Thomas Andraschko <
> > andraschko.tho...@gmail.com>
> > a écrit :
> >
> > > JPA is also about reading the JPA XML descriptors and resolving
> > > EntityManagers, which is both heavily used in the Data module.
> > > So its currently much more than TX. I would rename it to ds-persistence
> > and
> > > ds-faces.
> > >
> > > Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> > > gpetra...@apache.org>:
> > >
> > > > hi thomas,
> > > >
> > > > we need to fix the rat-check (see [1]).
> > > >
> > > > @renaming the modules:
> > > > the jpa-module was always mainly about the "entitymanager" +
> > > > "transaction" (see the package-naming)... with the main focus on
> > > > transactions (see @Transactional and @TransactionScoped as the main
> > > > api).
> > > > therefore we almost renamed it to ds-tx (in the beginning). we just
> > > > kept 'jpa', because it wasn't clear what we might add later on.
> > > > maybe we should just start a community-poll about it.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > > [1]
> > > >
> > https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> > > >
> > > >
> > > >
> > > > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > > > :
> > > > >
> > > > > Hi,
> > > > >
> > > > > last week i had some time and migrated almost all still existing
> > > modules
> > > > to
> > > > > Jakarta. Only scheduler is currently not migrated.
> > > > > AFAICS servlet, bean-validation has been removed, also other small
> > > pieces
> > > > > of core.
> > > > >
> > > > > I would also like to rename jpa and jsf to their new jakarta name
> > > > > (persistence and faces).
> > > > > WDYT guys?
> > > > >
> > > > > After that rename and reintroduce the scheduler module, i would be
> > > happy
> > > > > enough to release a RC1.
> > > > >
> > > > > AFAICS a big missing part are the tests on real containers?!
> > > > > Any other topics we need to address?
> > > > >
> > > > > Best regards,
> > > > > Thomas
> > > >
> > >
> >
>

Re: Jakarta EE / DeltaSpike 2.0 Status

[Romain Manni-Bucau]

Hi,

Do we have some visibility about the usage?
Think jpa/tx feature tend to disappear in new applications because JTA got
it (we like or not the design is another thing but feature is there
built-in now comared to when DS was created).
So for a new major we can aim at dropping it - keeping in 1.x.
About data module I guess the adoption is not that high even if module is
really "cool" - guess we miss the jaxrs bridge but we never got any request
about it - so not sure its future.
It can likely be the same for almost all core module which is now almost
standard in CDI or Microprofile/coming Jakarta (idea being to not bring
things without added value in time for a new major).

So overall I wouldnt aim at renaming but more pruning what is built in or
will be soon and make DS lighter now resources are very low and the need of
the project really less important than years ago.

Hope it makes sense.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 4 avr. 2023 à 09:57, Thomas Andraschko 
a écrit :

> JPA is also about reading the JPA XML descriptors and resolving
> EntityManagers, which is both heavily used in the Data module.
> So its currently much more than TX. I would rename it to ds-persistence and
> ds-faces.
>
> Am Mo., 3. Apr. 2023 um 19:20 Uhr schrieb Gerhard Petracek <
> gpetra...@apache.org>:
>
> > hi thomas,
> >
> > we need to fix the rat-check (see [1]).
> >
> > @renaming the modules:
> > the jpa-module was always mainly about the "entitymanager" +
> > "transaction" (see the package-naming)... with the main focus on
> > transactions (see @Transactional and @TransactionScoped as the main
> > api).
> > therefore we almost renamed it to ds-tx (in the beginning). we just
> > kept 'jpa', because it wasn't clear what we might add later on.
> > maybe we should just start a community-poll about it.
> >
> > regards,
> > gerhard
> >
> > [1]
> > https://ci-builds.apache.org/job/DeltaSpike/job/DeltaSpike%20RAT-Check/
> >
> >
> >
> > Am Mo., 3. Apr. 2023 um 16:08 Uhr schrieb Thomas Andraschko
> > :
> > >
> > > Hi,
> > >
> > > last week i had some time and migrated almost all still existing
> modules
> > to
> > > Jakarta. Only scheduler is currently not migrated.
> > > AFAICS servlet, bean-validation has been removed, also other small
> pieces
> > > of core.
> > >
> > > I would also like to rename jpa and jsf to their new jakarta name
> > > (persistence and faces).
> > > WDYT guys?
> > >
> > > After that rename and reintroduce the scheduler module, i would be
> happy
> > > enough to release a RC1.
> > >
> > > AFAICS a big missing part are the tests on real containers?!
> > > Any other topics we need to address?
> > >
> > > Best regards,
> > > Thomas
> >
>

[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678135#comment-17678135
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1434:


CDI 4.0 is not backward compatible with CDI 3.0 (both in jakarta namespace), it 
requires some codechange to ensure it can run on both but can also mean we drop 
CDI 1.0 support (supporting 1, 2 and 4 is way harder than 2-4). Surely 
something to discuss on the list.

> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems 
> to be required to use deltaspike in the future. 
> https://jakarta.ee/compatibility/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release Apache DeltaSpike-1.9.6

[Romain Manni-Bucau]

+1

Le ven. 8 avr. 2022 à 21:39, Alexander Falb  a écrit :

> +1
>
> On Fri, Apr 8, 2022 at 6:27 PM Mark Struberg 
> wrote:
>
> > Hi lords and ladies!
> >
> > I'd like to call a VOTE on releasing Apache DeltaSpike-1.9.6
> >
> > The following tickets got resolved:
> >
> >
> > Bug
> > [DELTASPIKE-1133] - Don't override the log level
> > [DELTASPIKE-1427] - JUL Logging with {} as param leeds to
> > NumberFormatException
> > [DELTASPIKE-1433] - EntityManagerFactoryProducer should also provide
> a
> > @Disposes method
> > [DELTASPIKE-1453] - injecting config of Class got broken
> >
> > New Feature
> > [DELTASPIKE-1431] - add easy way to disable InvocationResultLogger
> > [DELTASPIKE-1444] - Create POJO and Record based Config
> > [DELTASPIKE-1445] - Dynamic Config injection via a Supplier
> >
> > Improvement
> > [DELTASPIKE-1426] - DeltaSpikeProxyFactory is slow on start
> > [DELTASPIKE-1432] - Proxy class definition does not work
> > [DELTASPIKE-1454] - Upgrade ASM to 9.3
> >
> > Task
> > [DELTASPIKE-1452] - upgrade to apache-parent 25
> >
> >
> >
> > The staging repository can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/
> > <
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/
> > >
> >
> > The source repo is located at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/org/apache/deltaspike/deltaspike/1.9.6/
> > <
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1058/org/apache/deltaspike/deltaspike/1.9.6/
> > >
> > sha512 is
> >
> ae2b2b183a54b9dff00d78a8f3a60fc87bde701599390a437970b218c208cb636d058fa596d0ab0ac3dfa9dd022c383c59f9ac6f5bab4e3bfe47db0a063af490
> >
> > Please VOTE
> >
> > [+1] yeah, ship it!
> > [+0] meh, don't care
> > [-1]  stop there is a ${showstopper}
> >
> > The VOTE is open for 72h.
> >
> > txs and LieGrue,
> > strub
> >
> >
> >
>

Re: jira cleanup

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 6 avr. 2022 à 16:58, Mark Struberg  a
écrit :

> hi folks!
>
> I'd love to go through our old tickets and close feature requests where we
> didn't receive any contributions as won't fix.
> Once people pop up again and ship patches I'm happy to open them up again.
>
> wdyt?
>
> LieGrue,
> strub
>
>

Re: some draft for DS-2.0

[Romain Manni-Bucau]

Without feature change I would still prefer the shade/relocation + bom
option instead of 2 branches (recall you didnt maintain your
geronimo-config branches? ;))

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le sam. 25 sept. 2021 à 09:38, Thomas Andraschko <
andraschko.tho...@gmail.com> a écrit :

> Mark, AFAICS you did it in a new main branch instead of master?
> I would move master to 1.9.x branch and do 2.x in master
>
> Why isnt it in GitHub?
>
> Thomas Andraschko  schrieb am Do., 23. Sept.
> 2021, 21:33:
>
> > +1 for making it master
> >
> > Mark Struberg  schrieb am Do., 23. Sept.
> 2021,
> > 20:13:
> >
> >> hi!
> >>
> >> I've migrated a few things over to the jakarta namespace and started
> >> dropping a few old features.
> >> Right now it's just core which I got working, but will now also move
> over
> >> module by module.
> >>
> >> The draft can be viewed here:
> >> https://github.com/struberg/deltaspike/tree/fb_ds20 <
> >> https://github.com/struberg/deltaspike/tree/fb_ds20>
> >> What branch name do we want to give it finally? Take the chance to
> switch
> >> to 'main' and somewhat later rename the master branch to mt_ds1.x?
> >>
> >> How did I proceed?
> >> I did not yet delete anything. Pieces which I do not see as part of
> >> DS-2.0 got moved to an 'obsolete' directory with the same structure. If
> we
> >> figure that we do still want to keep some of the features, then we can
> >> simply move those files back without loosing any history.
> >>
> >> Happ to get feedback!
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
>

Re: [DISCUSS] Apache DeltaSpike 2.0 targeting Java 17 and Jakarta-9.0

[Romain Manni-Bucau]

Question is more: does it fit another project more adapted?

Le sam. 11 sept. 2021 à 20:53, Mark Struberg  a
écrit :

> ds-core has still a ton of useful unique features.
> DS-config is probably the most mature config systems out there.
>

Guess it can fall in G-config which matches mp-config and both can target
more users instead of twice a few?

@Exclude together with config -> feature switch on stereoids. I don't know
> any other project which provides this.
>

Right but also less and less useful due to the way apps are written and the
acceptation of veto() in extensions by users.

@MessageBundle is another neat feature
>

Never saw it used in real projects except redhat ones but with additional
required features.

ProjectStage yet another
>

Likely wrong since it uses a lib namespace and not an app one + always
replaced by an env/system prop in practise.

So i agree ideas are great but too java (overengineered) to be embraced
widely.
This is why i proposed to split it where it fits and does not have a more
adopted replacement.



> Other modules are still really worth it, e.g. the jpa module with
> @Transactional. This is still great since jakarta took over the broken
> javax.transaction.Transactional with the same borked Exception semantics
> like EJB.
>

Not broken, just not the one you would like ;).
Once you know it you make it 1-1 functionally.


> There is for sure a lot which can be ditched. E.g. exception eventing,
> injectable file resources, etc.
>

Some could defend it the same you defended other features.
Figures tend to show people replaced it - i assume quarkus not cdi support
didnt help - so question about the future and other projects interactions
should be done IMHO.


> But there is plenty of great stuff in here still.
>
> LieGrue,
> strub
>
> > Am 11.09.2021 um 18:48 schrieb Romain Manni-Bucau  >:
> >
> > Le sam. 11 sept. 2021 à 18:46, Thomas Andraschko <
> > andraschko.tho...@gmail.com> a écrit :
> >
> >> true romain
> >>
> >> i think the most features can you go into the the spec (e.g. CDI event
> >> broadcast of JSF events should be in JSF directly)
> >> i think the biggest module is Data, which cant be easily put into JPA
> >>
> >
> > Can go into openjpa but i didnt see a lot of adoption so can stay in 1.x
> i
> > guess
> >
> >
> >
> >> Am Sa., 11. Sept. 2021 um 18:42 Uhr schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com>:
> >>
> >>> Well transitive dep issue is solved with proper boms.
> >>> Think we should ask ourselves the future of DS.
> >>> Im not fully convinced of the added value these days in current IT
> >>> ecosystem so maybe it should be split in subprojects and some full
> parts
> >>> dropped or given to other asf projects?
> >>>
> >>> Le sam. 11 sept. 2021 à 17:29, Thomas Andraschko <
> >>> andraschko.tho...@gmail.com> a écrit :
> >>>
> >>>> see:
> >>>>
> >>>>
> >>>
> >>
> https://issues.apache.org/jira/browse/DELTASPIKE-1376?jql=project%20%3D%20DELTASPIKE%20AND%20fixVersion%20%3D%202.0
> >>>>
> >>>> Am Sa., 11. Sept. 2021 um 17:25 Uhr schrieb Thomas Andraschko <
> >>>> andraschko.tho...@gmail.com>:
> >>>>
> >>>>> +1
> >>>>>
> >>>>> i created some jira tickets for it 1-2 years ago
> >>>>>
> >>>>> Am Sa., 11. Sept. 2021 um 14:58 Uhr schrieb Cody Lerum <
> >>>>> cody.le...@gmail.com>:
> >>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> 1.9.x seems very stable with minimal updates so it is unlikely to be
> >>>>>> much of a burden to keep it alive for pre-Jakarta use.
> >>>>>>
> >>>>>> I could see some people say setting a JDK 17 minimum would be
> >>>>>> aggressive, but those starting new Jakarta projects or going through
> >>>>>> the upgrade work for an older project should really be moving up to
> >>>>>> it.
> >>>>>>
> >>>>>> -C
> >>>>>>
> >>>>>> On Sat, Sep 11, 2021 at 6:48 AM Mark Struberg
> >>>  >>>>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi folks!
> >>>>>>>
> >>>>>>> There was a bunch of user requests on the mailing list  to add
> >>> support
&g

Re: [DISCUSS] Apache DeltaSpike 2.0 targeting Java 17 and Jakarta-9.0

[Romain Manni-Bucau]

Le sam. 11 sept. 2021 à 18:46, Thomas Andraschko <
andraschko.tho...@gmail.com> a écrit :

> true romain
>
> i think the most features can you go into the the spec (e.g. CDI event
> broadcast of JSF events should be in JSF directly)
> i think the biggest module is Data, which cant be easily put into JPA
>

Can go into openjpa but i didnt see a lot of adoption so can stay in 1.x i
guess



> Am Sa., 11. Sept. 2021 um 18:42 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>
> > Well transitive dep issue is solved with proper boms.
> > Think we should ask ourselves the future of DS.
> > Im not fully convinced of the added value these days in current IT
> > ecosystem so maybe it should be split in subprojects and some full parts
> > dropped or given to other asf projects?
> >
> > Le sam. 11 sept. 2021 à 17:29, Thomas Andraschko <
> > andraschko.tho...@gmail.com> a écrit :
> >
> > > see:
> > >
> > >
> >
> https://issues.apache.org/jira/browse/DELTASPIKE-1376?jql=project%20%3D%20DELTASPIKE%20AND%20fixVersion%20%3D%202.0
> > >
> > > Am Sa., 11. Sept. 2021 um 17:25 Uhr schrieb Thomas Andraschko <
> > > andraschko.tho...@gmail.com>:
> > >
> > > > +1
> > > >
> > > > i created some jira tickets for it 1-2 years ago
> > > >
> > > > Am Sa., 11. Sept. 2021 um 14:58 Uhr schrieb Cody Lerum <
> > > > cody.le...@gmail.com>:
> > > >
> > > >> +1
> > > >>
> > > >> 1.9.x seems very stable with minimal updates so it is unlikely to be
> > > >> much of a burden to keep it alive for pre-Jakarta use.
> > > >>
> > > >> I could see some people say setting a JDK 17 minimum would be
> > > >> aggressive, but those starting new Jakarta projects or going through
> > > >> the upgrade work for an older project should really be moving up to
> > > >> it.
> > > >>
> > > >> -C
> > > >>
> > > >> On Sat, Sep 11, 2021 at 6:48 AM Mark Struberg
> >  > > >
> > > >> wrote:
> > > >> >
> > > >> > Hi folks!
> > > >> >
> > > >> > There was a bunch of user requests on the mailing list  to add
> > support
> > > >> for Jakarta enterprise namespaces.
> > > >> > I tried to implement this via shading but it seems not to be
> > > sufficient.
> > > >> > The problem with shading is that the poms only have classifier to
> > > >> access deltaspike.
> > > >> > This is especially a problem with transitive dependencies.
> > > >> >
> > > >> > The other point is that we had many discussions about shipping an
> > > >> upgraded version of DeltaSpike and deprecate/remove some obsolete
> > APIs.
> > > >> > So let's go big and why not move up to jakartaEE namespace and
> > Java17
> > > >> at the same time?
> > > >> >
> > > >> > Potential candidates for dropping coming to my mind:
> > > >> >
> > > >> > .) BeanManagerProvider/BeanProvider. We historically kept this
> for 2
> > > >> reasons. 1.) backward compatibility with CDI-1.0, 2.) in EARs this
> is
> > > still
> > > >> the only way which works to properly access the BeanManager on all
> > > >> containers. CDI.current() is sadly broken in EARs in almost all
> > > containers.
> > > >> But since EARs might go away in JakartaEE anyways, I'm fine with
> > > dropping
> > > >> it.
> > > >> >
> > > >> > .) servlet module. Injecting the various servlet information
> objects
> > > >> like HttpServletRequest, HttpSession etc is nowadays specified by
> the
> > > CDI
> > > >> spec as well.
> > > >> >
> > > >> > .) Many parts of the JSF module are nowadays not needed anymore as
> > > >> well. Remember the times when there was no injection into
> > PhaseListeners
> > > >> and FacesConverters? We did have support for it since ages, the spec
> > > added
> > > >> this much later, but they finally did.
> > > >> >
> > > >> > .) bean validation module. Those parts are imo all part of the
> spec
> > > >> nowadays
> > > >> >
> > > >> > .) scheduler. I'm not sure about that one. It probably would make
> > > sense
> > > >> to implement an own smallish scheduler based on ScheduledExecutor
> > > instead
> > > >> of going fully blown quartz?
> > > >> >
> > > >> >
> > > >> >
> > > >> > wdyt?
> > > >> >
> > > >> > I'd go on and create a new umbrella ticket for all the work.
> > > >> >
> > > >> > LieGrue,
> > > >> > strub
> > > >> >
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: [DISCUSS] Apache DeltaSpike 2.0 targeting Java 17 and Jakarta-9.0

[Romain Manni-Bucau]

Well transitive dep issue is solved with proper boms.
Think we should ask ourselves the future of DS.
Im not fully convinced of the added value these days in current IT
ecosystem so maybe it should be split in subprojects and some full parts
dropped or given to other asf projects?

Le sam. 11 sept. 2021 à 17:29, Thomas Andraschko <
andraschko.tho...@gmail.com> a écrit :

> see:
>
> https://issues.apache.org/jira/browse/DELTASPIKE-1376?jql=project%20%3D%20DELTASPIKE%20AND%20fixVersion%20%3D%202.0
>
> Am Sa., 11. Sept. 2021 um 17:25 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
> > +1
> >
> > i created some jira tickets for it 1-2 years ago
> >
> > Am Sa., 11. Sept. 2021 um 14:58 Uhr schrieb Cody Lerum <
> > cody.le...@gmail.com>:
> >
> >> +1
> >>
> >> 1.9.x seems very stable with minimal updates so it is unlikely to be
> >> much of a burden to keep it alive for pre-Jakarta use.
> >>
> >> I could see some people say setting a JDK 17 minimum would be
> >> aggressive, but those starting new Jakarta projects or going through
> >> the upgrade work for an older project should really be moving up to
> >> it.
> >>
> >> -C
> >>
> >> On Sat, Sep 11, 2021 at 6:48 AM Mark Struberg  >
> >> wrote:
> >> >
> >> > Hi folks!
> >> >
> >> > There was a bunch of user requests on the mailing list  to add support
> >> for Jakarta enterprise namespaces.
> >> > I tried to implement this via shading but it seems not to be
> sufficient.
> >> > The problem with shading is that the poms only have classifier to
> >> access deltaspike.
> >> > This is especially a problem with transitive dependencies.
> >> >
> >> > The other point is that we had many discussions about shipping an
> >> upgraded version of DeltaSpike and deprecate/remove some obsolete APIs.
> >> > So let's go big and why not move up to jakartaEE namespace and Java17
> >> at the same time?
> >> >
> >> > Potential candidates for dropping coming to my mind:
> >> >
> >> > .) BeanManagerProvider/BeanProvider. We historically kept this for 2
> >> reasons. 1.) backward compatibility with CDI-1.0, 2.) in EARs this is
> still
> >> the only way which works to properly access the BeanManager on all
> >> containers. CDI.current() is sadly broken in EARs in almost all
> containers.
> >> But since EARs might go away in JakartaEE anyways, I'm fine with
> dropping
> >> it.
> >> >
> >> > .) servlet module. Injecting the various servlet information objects
> >> like HttpServletRequest, HttpSession etc is nowadays specified by the
> CDI
> >> spec as well.
> >> >
> >> > .) Many parts of the JSF module are nowadays not needed anymore as
> >> well. Remember the times when there was no injection into PhaseListeners
> >> and FacesConverters? We did have support for it since ages, the spec
> added
> >> this much later, but they finally did.
> >> >
> >> > .) bean validation module. Those parts are imo all part of the spec
> >> nowadays
> >> >
> >> > .) scheduler. I'm not sure about that one. It probably would make
> sense
> >> to implement an own smallish scheduler based on ScheduledExecutor
> instead
> >> of going fully blown quartz?
> >> >
> >> >
> >> >
> >> > wdyt?
> >> >
> >> > I'd go on and create a new umbrella ticket for all the work.
> >> >
> >> > LieGrue,
> >> > strub
> >> >
> >> >
> >>
> >
>

Re: [VOTE] Release Apache DeltaSpike-1.9.5

[Romain Manni-Bucau]

+1

Le sam. 6 mars 2021 à 01:08, Daniel Dias Dos Santos <
daniel.dias.analist...@gmail.com> a écrit :

> Hello ,
>
> +1
>
> On Fri, Mar 5, 2021, 19:45 Mark Struberg 
> wrote:
>
> > Hi Lords and Ladies!
> >
> > I'd like to call a VOTE for releasing Apache DeltaSpike-1.9.5
> >
> > The following tickets got closed:
> > Bug
> >
> > [DELTASPIKE-1314  >]
> > - ContainerCtrlTckTest fails with tomee7-build-managed
> > [DELTASPIKE-1413  >]
> > - dsrwid cookie should not be set to sameSite="None"
> > [DELTASPIKE-1416  >]
> > - deltaspike-core-impl.jar does not contain the Main class to execute in
> > your Manifest.MF to Crypto
> > [DELTASPIKE-1423  >]
> > - JSF-2.3 managed() in FacesValidator and FacesConverter break CDI
> > integration
> > Improvement
> >
> > [DELTASPIKE-1420  >]
> > - Update ASM to 9.1
> >
> >
> > The staging repository is
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1056/
> > <
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1056/
> > >
> >
> > The source zip can be found at
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1056/org/apache/deltaspike/deltaspike/1.9.5/
> > <
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1056/org/apache/deltaspike/deltaspike/1.9.5/
> > >
> > sha1 is fa8779819026c86320959ffb7d1ce6546b6ad1e2
> >
> > Please VOTE
> >
> > [+1] yikes, go ship it!
> > [+0] meh, don't care
> > [-1] nah stop, there is a ${showstopper}
> >
> > The VOTE is open for 72h.
> >
> > LieGrue,
> > strub
> >
> >
>

Re: [VOTE] Release Apache DeltaSpike-1.9.4

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 3 juin 2020 à 13:58, Daniel Dias Dos Santos <
daniel.dias.analist...@gmail.com> a écrit :

> +1
> --
>
> *Daniel Dias dos Santos*
> Java Developer
> SouJava & JCP Member
> GitHub: https://github.com/Daniel-Dos
> Linkedin: www.linkedin.com/in/danieldiasjava
> Twitter: http://twitter.com/danieldiasjava
>
>
> Em qua., 3 de jun. de 2020 às 04:44, Mark Struberg
>  escreveu:
>
> > Hi!
> >
> > I've rolled the release for Apache DeltaSpike-1.9.4
> >
> > The following tickets got resolved:
> >
> > Bug
> >
> > [DELTASPIKE-1403 <https://issues.apache.org/jira/browse/DELTASPIKE-1403
> >]
> > - Site has no reference to the release of version 1.9.3
> > [DELTASPIKE-1408 <https://issues.apache.org/jira/browse/DELTASPIKE-1408
> >]
> > - Some Weld versions fail on CDI.current() depending on the ClassLoader
> > setup
> > [DELTASPIKE-1409 <https://issues.apache.org/jira/browse/DELTASPIKE-1409
> >]
> > - ProjectStageTestControlTest doesn't work on Weld2
> > Improvement
> >
> > [DELTASPIKE-1358 <https://issues.apache.org/jira/browse/DELTASPIKE-1358
> >]
> > - Move shaded ASM classes from proxy-impl into a separate JAR or update
> ASM
> > [DELTASPIKE-1402 <https://issues.apache.org/jira/browse/DELTASPIKE-1402
> >]
> > - ~/.deltaspike/apache-deltaspike.properties doesn't pickup changes
> during
> > runtime
> > [DELTASPIKE-1405 <https://issues.apache.org/jira/browse/DELTASPIKE-1405
> >]
> > - upgrade to apache-parent 23 and fix distribution
> > Wish
> >
> > [DELTASPIKE-1397 <https://issues.apache.org/jira/browse/DELTASPIKE-1397
> >]
> > - Detect the cycled variable references
> > Task
> >
> > [DELTASPIKE-1404 <https://issues.apache.org/jira/browse/DELTASPIKE-1404
> >]
> > - News links to post and examples.
> >
> > The staging repo can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1055/
> > <
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1055/
> > >
> >
> > commit in our git repo is 370c0136ec5f597aee0c49b443a200ef0e3590e3
> >
> > The source zip is:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1055/org/apache/deltaspike/deltaspike/1.9.4/
> > <
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1055/org/apache/deltaspike/deltaspike/1.9.4/
> > >
> > sha1 is 49238449e9d37de1108cd353b6e4b2c476cfaf46
> >
> >
> > Please VOTE:
> > [+1] let's ship it
> > [0] meh, don't care
> > [-1] stop there is a ${showstopper}
> >
> > The VOTE is open for 72h
> >
> >
> > txs and LieGrue,
> > strub
> >
> >
> >
> >
>

[jira] [Comment Edited] (DELTASPIKE-1402) ~/.deltaspike/apache-deltaspike.properties doesn't pickup changes during runtime

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17120916#comment-17120916
 ] 

Romain Manni-Bucau edited comment on DELTASPIKE-1402 at 6/1/20, 10:38 AM:
--

I guess we need to refine the target:

 
 # hot reloading
 # bootstrap config (what if the config is mapped to a runtime model, it can be 
reloaded, it will never be refreshed)
 # immutable deployments (some deployments will not want to reload cause it 
means potentially breaking a valid deployment)
 # performances: most servlet container have a dev mode with reloading at read 
and a prod mode where it is disabled to avoid any IO which are cheap if done 
alone but can be expensive if the disk is used with an IO expensive app

Therefore I suspect we can need a toggle to enable a refresh at read or a 
cached mode (read once). Using an enum it can enable us to add later a 
background refresh if needed so I would add something like

 
{code:java}
deltaspike.configsource.userhome.reloadStrategy=[SYNCHRONOUS_AT_READ|NONE|SKIP]
{code}
Side note: SKIP means "I don't want that, most apps of that machine use it but 
not me"

Hope it makes sense.


was (Author: romain.manni-bucau):
I guess we need to refine the target:

 
 # hot reloading
 # bootstrap config (what if the config is mapped to a runtime model, it can be 
reloaded, it will never be refreshed)
 # immutable deployments (some deployments will not want to reload cause it 
means potentially breaking a valid deployment)
 # performances: most servlet container have a dev mode with reloading at read 
and a prod mode where it is disabled to avoid any IO which are cheap if done 
alone but can be expensive if the disk is used with an IO expensive app

Therefore I suspect we can need a toggle to enable a refresh at read or a 
cached mode (read once). Using an enum it can enable us to add later a 
background refresh if needed so I would add something like

 
{code:java}
deltaspike.configsource.userhome.reloadStrategy=[SYNCHRONOUS_AT_READ|NONE]
{code}
Hope it makes sense.

> ~/.deltaspike/apache-deltaspike.properties doesn't pickup changes during 
> runtime
> 
>
> Key: DELTASPIKE-1402
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1402
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Configuration
>Affects Versions: 1.9.3
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.9.4
>
>
> Right now the {{ConfigSource}} registered via 
> {{org.apache.deltaspike.core.impl.config.DefaultConfigSourceProvider#addUserHomeConfigSource}}
>  does not reload dynamically if the file got changed.
> That means DeltaSpike Config right now doesn't automatically pick up changes 
> in this file.
> The same is true for other 
> {{org.apache.deltaspike.core.impl.config.PropertyFileConfigSource}} but most 
> of them are in a jar anyway, so it doesn't make any difference.
> Of course for PropertyFileConfigSources representing native files on the disk 
> it might also be nice to detect dynamic changes.
> It might be perfectly fine to have changes only picked up based on the 
> last-changed timestamp of the file and only checked every minute or so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (DELTASPIKE-1402) ~/.deltaspike/apache-deltaspike.properties doesn't pickup changes during runtime

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17120916#comment-17120916
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1402:


I guess we need to refine the target:

 
 # hot reloading
 # bootstrap config (what if the config is mapped to a runtime model, it can be 
reloaded, it will never be refreshed)
 # immutable deployments (some deployments will not want to reload cause it 
means potentially breaking a valid deployment)
 # performances: most servlet container have a dev mode with reloading at read 
and a prod mode where it is disabled to avoid any IO which are cheap if done 
alone but can be expensive if the disk is used with an IO expensive app

Therefore I suspect we can need a toggle to enable a refresh at read or a 
cached mode (read once). Using an enum it can enable us to add later a 
background refresh if needed so I would add something like

 
{code:java}
deltaspike.configsource.userhome.reloadStrategy=[SYNCHRONOUS_AT_READ|NONE]
{code}
Hope it makes sense.

> ~/.deltaspike/apache-deltaspike.properties doesn't pickup changes during 
> runtime
> 
>
> Key: DELTASPIKE-1402
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1402
> Project: DeltaSpike
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Configuration
>Affects Versions: 1.9.3
>Reporter: Mark Struberg
>Priority: Major
> Fix For: 1.9.4
>
>
> Right now the {{ConfigSource}} registered via 
> {{org.apache.deltaspike.core.impl.config.DefaultConfigSourceProvider#addUserHomeConfigSource}}
>  does not reload dynamically if the file got changed.
> That means DeltaSpike Config right now doesn't automatically pick up changes 
> in this file.
> The same is true for other 
> {{org.apache.deltaspike.core.impl.config.PropertyFileConfigSource}} but most 
> of them are in a jar anyway, so it doesn't make any difference.
> Of course for PropertyFileConfigSources representing native files on the disk 
> it might also be nice to detect dynamic changes.
> It might be perfectly fine to have changes only picked up based on the 
> last-changed timestamp of the file and only checked every minute or so.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (DELTASPIKE-1366) Add Junit5 testing support

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111798#comment-17111798
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1366:


[~Sethi] you can exclude openwebbeans transitive deps and it works with weld, 
just dependencies management stuff (indeed by default it brings owb ;)). I see 
no issue to bring it to DS if it does not depend on any other DS module though.

> Add Junit5 testing support
> --
>
> Key: DELTASPIKE-1366
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1366
> Project: DeltaSpike
>  Issue Type: Wish
>  Components: TestControl, Tests
>Affects Versions: 1.9.0
>Reporter: John Smith
>Priority: Major
>
> Are there any plans to provide a junit5 extension like the CdiTestRunner in 
> the test-control module for junit4? 
> {{Especially the feature of the DynamicMockManager that allows you to add 
> mocks on per test basis is pretty nice for testing.}}
> {{This would be highly appreciated.  }}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (DELTASPIKE-1366) Add Junit5 testing support

[Romain Manni-Bucau (Jira)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17111449#comment-17111449
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1366:


Hi, if it helps, openwebbeans-junit5 is just a wrapper around CDI 2 SeContainer 
so portable accross CDI implementation (once the implementation dependency 
selected) and is already available since some time 
[http://openwebbeans.apache.org/openwebbeans-junit5.html]. Can fill the gap and 
avoid the legacy CdiTestRunner relies on (thinking about BeanProvider and 
CdiCtrl which were pre-CDI 2).

> Add Junit5 testing support
> --
>
> Key: DELTASPIKE-1366
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1366
> Project: DeltaSpike
>  Issue Type: Wish
>  Components: TestControl, Tests
>Affects Versions: 1.9.0
>Reporter: John Smith
>Priority: Major
>
> Are there any plans to provide a junit5 extension like the CdiTestRunner in 
> the test-control module for junit4? 
> {{Especially the feature of the DynamicMockManager that allows you to add 
> mocks on per test basis is pretty nice for testing.}}
> {{This would be highly appreciated.  }}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Release Apache DeltaSpike-1.9.3

[Romain Manni-Bucau]

+1

Le mar. 28 janv. 2020 à 21:09, Thomas Andraschko <
andraschko.tho...@gmail.com> a écrit :

> +1
>
> Am Di., 28. Jan. 2020 um 21:00 Uhr schrieb Daniel Cunha <
> daniels...@gmail.com>:
>
> > +1
> >
> > Em ter., 28 de jan. de 2020 às 12:17, Mark Struberg
> >  escreveu:
> >
> > > Hi!
> > >
> > > We are about to release Apache DeltaSpike-1.9.3.
> > > This release fixes a security issue for our ClientSideWindowHandler.
> > >
> > > The staging repo can be found here:
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1054
> > >
> > > The source release can be found here
> > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1054/org/apache/deltaspike/deltaspike/1.9.3/
> > > sha1
> > > <
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1054/org/apache/deltaspike/deltaspike/1.9.3/sha1
> > >
> > > is 6c822278d187dee6f9167dbdf630feab633ec4f3
> > >
> > > Please VOTE
> > >
> > > [+1] go ship it
> > > [+0] meh, don't care
> > > [-1] stop, there is a ${showstopper}
> > >
> > > The VOTE is open for 72h
> > >
> > > txs and LieGrue,
> > > strub
> > >
> > >
> >
> > --
> > Daniel "soro" Cunha
> > https://twitter.com/dvlc_
> >
>

Re: DeltaSpike 1.9.2?

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le jeu. 12 déc. 2019 à 13:30, Thomas Andraschko 
a écrit :

> Hi,
>
> i would like to trigger the release process today.
> Everyone ok with it?
>
> Best regards,
> Thomas
>

Re: [DISUSS] do a 1.9.2 release?

[Romain Manni-Bucau]

+1

Le ven. 15 nov. 2019 à 11:14, Thomas Andraschko 
a écrit :

> +1
>
> Am Fr., 15. Nov. 2019 um 11:13 Uhr schrieb Mark Struberg
> :
>
> > Hi folks!
> >
> > What do you think about running a DeltaSpike-1.9.2 release?
> >
> > LieGrue,
> > strub
> >
> >
>

Re: [VOTE] Release of Apache DeltaSpike 1.9.1

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 13 août 2019 à 15:33, Thomas Andraschko 
a écrit :

> Hi,
>
> I was running the needed tasks to get the 1.9.1 release of Apache
> DeltaSpike out.
> The artifacts are deployed to Nexus [1] (and [2]).
>
> The tag is available at [3] and will get pushed to the ASF repository
> once the vote passed.
>
> Please take a look at the 1.9.1 artifacts and vote!
>
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes (see
> [4]).
>
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be
> released, and why..
> 
>
> Thanks,
> Thomas
>
> [1]
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1051/
> [2]
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1051/org/apache/deltaspike/deltaspike/[version]/deltaspike-[version]-source-release.zip
> [3] https://github.com/tandraschko/deltaspike-vote/tree/deltaspike-1.9.1
> [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
>

[jira] [Commented] (DELTASPIKE-193) Setup SecurityManager enabled CI build

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825085#comment-16825085
 ] 

Romain Manni-Bucau commented on DELTASPIKE-193:
---

Think it is worth doing it since apps can run under a SM so while we are a lib 
we must comply to that requirement IMHO.

> Setup SecurityManager enabled CI build
> --
>
> Key: DELTASPIKE-193
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-193
> Project: DeltaSpike
>  Issue Type: Task
>  Components: Build
>Affects Versions: 0.2-incubating
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
>
> We currently don't have any CI environment which uses a SecurityManager. We 
> should add such an environment to check whether DeltaSpike properly uses 
> doPrivileged blocks where needed. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Move our git repo to Apache gitbox

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 7 janv. 2019 à 18:08, Mark Struberg  a
écrit :

> Hi folks!
>
> I've made good experience with gitbox in other ASF projects.
> I'd say we just call it 'deltaspike' as is. We just have one repo, so that
> would be a 1:1 migration.
> As with everything GIT the sha1 doesn'T change anyway...
>
> Can I pull the trigger?
>
> Here is my +1
>
> The VOTE is open for 72h
>
> LieGrue,
> strub
>
> > Am 03.01.2019 um 14:19 schrieb Apache Infrastructure Team <
> infrastruct...@apache.org>:
> >
> > Hello, deltaspike folks.
> > As stated earlier in 2018, all git repositories must be migrated from
> > the git-wip-us.apache.org URL to gitbox.apache.org, as the old service
> > is being decommissioned. Your project is receiving this email because
> > you still have repositories on git-wip-us that needs to be migrated.
> >
> > The following repositories on git-wip-us belong to your project:
> > - deltaspike.git
> >
> >
> > We are now entering the mandated (coordinated) move stage of the roadmap,
> > and you are asked to please coordinate migration with the Apache
> > Infrastructure Team before February 7th. All repositories not migrated
> > on February 7th will be mass migrated without warning, and we'd
> appreciate
> > it if we could work together to avoid a big mess that day :-).
> >
> > Moving to gitbox means you will get full write access on GitHub as well,
> > and be able to close/merge pull requests and much more.
> >
> > To have your repositories moved, please follow these steps:
> >
> > - Ensure consensus on the move (a link to a lists.apache.org thread will
> >  suffice for us as evidence).
> > - Create a JIRA ticket at https://issues.apache.org/jira/browse/INFRA
> >
> > Your migration should only take a few minutes. If you wish to migrate
> > at a specific time of day or date, please do let us know in the ticket.
> >
> > As always, we appreciate your understanding and patience as we move
> > things around and work to provide better services and features for
> > the Apache Family.
> >
> > Should you wish to contact us with feedback or questions, please do so
> > at: us...@infra.apache.org.
> >
> >
> > With regards,
> > Apache Infrastructure
> >
>
>

Re: Merge PRs

[Romain Manni-Bucau]

You pull them locally, merge and then push on asf, once "ok" you can ask
the author to close it on github

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le lun. 12 nov. 2018 à 10:53, Thomas Andraschko 
a écrit :

> hmmm, how should we handle those pull requests then?
>
> Am Mo., 12. Nov. 2018 um 10:40 Uhr schrieb Mark Struberg
> :
>
> > Hi Thomas!
> >
> > DeltaSpike is not managed via gitbox but as a classic GIT repo.
> > Thus merging via github simply does not work.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 12.11.2018 um 09:37 schrieb Thomas Andraschko <
> > andraschko.tho...@gmail.com>:
> > >
> > > Hi,
> > >
> > > i would like to merge 2 PRs and close 1 PRs but it seems that i don't
> > have
> > > write access.
> > > However, i have write access to MF + OWB. So i wonder what additional
> > steps
> > > i need to do, to get write access?
> > >
> > > Best regards,
> > > Thomas
> >
> >
>

[jira] [Commented] (DELTASPIKE-1357) Update ASM to 6.2.1 for preliminary Java 12 support

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633615#comment-16633615
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1357:


maybe we should go straight on asm 7-beta which got released 2 days ago? 6.2.1 
does not support java 11 properly.

> Update ASM to 6.2.1 for preliminary Java 12 support
> ---
>
> Key: DELTASPIKE-1357
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1357
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Proxy-Module
>Affects Versions: 1.9.0
>Reporter: Christian Beikov
>Priority: Major
> Fix For: 1.9.1
>
>
> Java 12 has a new class file version and ASM 6.2 does not yet have support 
> for that. ASM 6.2.1 on the other hand already does. Since it's a minor 
> update, please get that into 1.9.1 so we can start early testing with Java 12.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache DeltaSpike-1.9.0 (take2)

[Romain Manni-Bucau]

+1

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mer. 12 sept. 2018 à 08:36, Mark Struberg  a
écrit :

> and my own +1
>
> LieGrue,
> strub
>
> > Am 10.09.2018 um 08:54 schrieb Mark Struberg  >:
> >
> > Good morning!
> >
> > This is the second release attempt for DeltaSpike 1.9.0.
> >
> > John discovered that we missed a license header in the first run.
> > This is fixed now - thanks John for the catch!
> > I've also enabled the apache-rat-plugin to run every time and not only
> in a dedicated profile.
> >
> >
> > The staging repo can be found here:
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1049/
> >
> > The source release zip is here:
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1049/org/apache/deltaspike/deltaspike/1.9.0/
> > sha1: 18d39411a60b4cc6a5af2ab261b4f7cde8692096
> >
> > The following tickets got resolved since 1.8.2 (same as in the first
> take):
> >
> > Bug
> >
> >   • [DELTASPIKE-900] - ResourceLocalTransactionStrategy not working
> with multiple EntityManagers
> >   • [DELTASPIKE-1198] - BeanManagerProvider.isActive() returns true
> after container shutdown
> >   • [DELTASPIKE-1324] - @Transactional annotation at method level
> doesn't override the one at class level any more
> >   • [DELTASPIKE-1327] - EnvironmentPropertyConfigSource is not
> scannable?
> >   • [DELTASPIKE-1336] - Regression: deltaspike-cdictrl-weld 1.8.0
> depends on weld-api 1.1.Final
> >   • [DELTASPIKE-1344] - deltaspike-cdictrl-owb has a transient
> runtime dependency on Shrinkwrap and Arquillian
> >   • [DELTASPIKE-1349] - isProxyableClass should ignore methods from
> Object.class
> >   • [DELTASPIKE-1351] - Java 10: IllegalArgumentException in
> ClassReader.
> >   • [DELTASPIKE-1353] - null values as arguments in messagebundles
> lead to exceptions
> > New Feature
> >
> >   • [DELTASPIKE-1280] - Automatic support for count* methods in
> EntityRepository
> >   • [DELTASPIKE-1315] - EntityRepository should offer an
> findOptionalBy
> >   • [DELTASPIKE-1321] - Upgrade DeltaSpike to require Java8 as
> minimum version
> >   • [DELTASPIKE-1335] - allow atomic access to n different
> TypedResolver values
> > Improvement
> >
> >   • [DELTASPIKE-1277] - Force refresh of cached config values
> >   • [DELTASPIKE-1322] - clean up ConfigResolver
> >   • [DELTASPIKE-1326] - Clean up Java 8 support in data module
> >   • [DELTASPIKE-1339] - Add support for dynamic interceptor binding,
> added via Extension
> >   • [DELTASPIKE-1340] - Delegate to JPA 2.2 getResultStream
> >   • [DELTASPIKE-1341] - [perf] QueryProcessorFactory could reuse
> QueryProcessors
> >   • [DELTASPIKE-1342] - Upgrade to ASM 6.1 for Java 10 support
> >   • [DELTASPIKE-1346] - ProjectStageProducer should log changed
> values only if the value changed
> > Task
> >
> >   • [DELTASPIKE-1308] - Documentation of user home properties
> mechanism
> >   • [DELTASPIKE-1325] - actively release ConfigSources and
> ConfigFilters if they implement Autocloseable
> >
> >
> > Please VOTE:
> >
> > [+1] let's ship it!
> > [+0] meh, don't care
> > [-1] stop there is a ${showstopper}
> >
> >
> > The VOTE is open for 72h
> >
> > txs and LieGrue,
> > strub
>
>

Re: [VOTE] Release Apache DeltaSpike 1.9.0

[Romain Manni-Bucau]

+1

Le dim. 9 sept. 2018 18:51, Gerhard Petracek  a
écrit :

> +1
>
> regards,
> gerhard
>
>
>
> Am Fr., 7. Sep. 2018 um 14:04 Uhr schrieb Mark Struberg
> :
>
> > Good afternoon!
> >
> > I'd like to call a VOTE on releasing Apache DeltaSpike 1.9.0.
> > This is the first version which requires Java8 as minimum Java version!
> > Apart from that it introduces a new SPI for our configuration system and
> > the ability to better deal with dynamic configuration values.
> >
> > The staging repo can be found here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1048/
> >
> > The source release zip is here:
> >
> >
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1048/org/apache/deltaspike/deltaspike/1.9.0/
> > sha1
> > <
> https://repository.apache.org/content/repositories/orgapachedeltaspike-1048/org/apache/deltaspike/deltaspike/1.9.0/sha1
> >:
> > d83b8174b2eaac0071606428dfc9792f8d0c6ff5
> >
> > The following tickets got resolved since 1.8.2:
> >
> > Bug
> >
> > • [DELTASPIKE-900] - ResourceLocalTransactionStrategy not working
> > with multiple EntityManagers
> > • [DELTASPIKE-1198] - BeanManagerProvider.isActive() returns true
> > after container shutdown
> > • [DELTASPIKE-1324] - @Transactional annotation at method level
> > doesn't override the one at class level any more
> > • [DELTASPIKE-1327] - EnvironmentPropertyConfigSource is not
> > scannable?
> > • [DELTASPIKE-1336] - Regression: deltaspike-cdictrl-weld 1.8.0
> > depends on weld-api 1.1.Final
> > • [DELTASPIKE-1344] - deltaspike-cdictrl-owb has a transient
> > runtime dependency on Shrinkwrap and Arquillian
> > • [DELTASPIKE-1349] - isProxyableClass should ignore methods from
> > Object.class
> > • [DELTASPIKE-1351] - Java 10: IllegalArgumentException in
> > ClassReader.
> > • [DELTASPIKE-1353] - null values as arguments in messagebundles
> > lead to exceptions
> > New Feature
> >
> > • [DELTASPIKE-1280] - Automatic support for count* methods in
> > EntityRepository
> > • [DELTASPIKE-1315] - EntityRepository should offer an
> > findOptionalBy
> > • [DELTASPIKE-1321] - Upgrade DeltaSpike to require Java8 as
> > minimum version
> > • [DELTASPIKE-1335] - allow atomic access to n different
> > TypedResolver values
> > Improvement
> >
> > • [DELTASPIKE-1277] - Force refresh of cached config values
> > • [DELTASPIKE-1322] - clean up ConfigResolver
> > • [DELTASPIKE-1326] - Clean up Java 8 support in data module
> > • [DELTASPIKE-1339] - Add support for dynamic interceptor
> binding,
> > added via Extension
> > • [DELTASPIKE-1340] - Delegate to JPA 2.2 getResultStream
> > • [DELTASPIKE-1341] - [perf] QueryProcessorFactory could reuse
> > QueryProcessors
> > • [DELTASPIKE-1342] - Upgrade to ASM 6.1 for Java 10 support
> > • [DELTASPIKE-1346] - ProjectStageProducer should log changed
> > values only if the value changed
> > Task
> >
> > • [DELTASPIKE-1308] - Documentation of user home properties
> > mechanism
> > • [DELTASPIKE-1325] - actively release ConfigSources and
> > ConfigFilters if they implement Autocloseable
> >
> >
> > Please VOTE:
> >
> > [+1] let's ship it!
> > [+0] meh, don't care
> > [-1] stop there is a ${showstopper}
> >
> >
> > The VOTE is open for 72h
> >
> > txs and LieGrue,
> > strub
> >
> >
> >
>

Re: Welcome Alex Falb as new Apache DeltaSpike

[Romain Manni-Bucau]

Welcome!

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 7 août 2018 à 08:53, Gerhard Petracek  a
écrit :

> welcome!
>
> regards,
> gerhard
>
>
>
> Am Di., 7. Aug. 2018 um 08:09 Uhr schrieb Mark Struberg
> :
>
> > Dear fellow Apache DeltaSpike users and devs.
> >
> > The Apache DeltaSpike PMC has voted on inviting Alex Falb as a new
> > committer to our project and he has accepted our invitation.
> >
> >
> > Welcome Alex!
> >
> >
> > the Apache DeltaSpike PMC
>

Re: where to place a Config-Diff algorigthm

[Romain Manni-Bucau]

Le mar. 5 juin 2018 à 10:25, Mark Struberg  a
écrit :

> Interesting solution, but I fear there are 2 problems with this:
> a.) It won't be backward compatible with existing ConfigSources out in the
> wild
>

Well we don't support it and the lasttimestamp solution has the same issue
so kind of status quo ;)


> b.) It's likely an overkill. That solution would make sense if you have a
> tons of changes, but not if there is barely something which moves.
>

Not really. it is more about: is the source pushing its changes or the
config polling them. I think the push solution is saner and in this case
doesn't require the polling and lasttimestamp at all, no?


>
> LieGrue,
> strub
>
> > Am 05.06.2018 um 09:34 schrieb Romain Manni-Bucau  >:
> >
> > Hmm, maybe too early so don't hesitate to shout if studid: why not
> having a
> > config manager sources can register in it and if this manager has >= 1
> > source then the thread is active otherwise it is destroyed
> > (running.set(false))
> > The source would be able to pass its refresh logic (as a function more or
> > less) the thread will execute in a safe manner (if fail - log but dont
> quit
> > the loop) and it returns a boolean to ask to propagate changes upstream
> or
> > not.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 5 juin 2018 à 09:23, Jean-Louis MONTEIRO  a
> > écrit :
> >
> >>>> Some values may have been updated, some might have been deleted and
> some
> >>>> other added.
> >>>> Returning a set might not be enough, isn't it?
> >>
> >>> We really only need the property names which got changed:
> >>> * new ones
> >>> * deleted ones
> >>> * the ones with different values
> >>>
> >>> So a Set is fine.
> >>
> >> The thing is that you will get the key of everything that changed which
> >> requires to invalidate the cache for all entries (lock?).
> >> Or you would need to iterate all the keys, compare again old/new and
> delete
> >> entries from cache, do nothing for add (? they will be lazily added
> during
> >> lookup maybe) and invalidate the updated values.
> >>
> >> That seems to be heavy to handle for nothing has during compare we have
> all
> >> information already.
> >>
> >>
> >>
> >> Le mar. 5 juin 2018 à 09:10, Mark Struberg 
> a
> >> écrit :
> >>
> >>> Hi JL!
> >>>
> >>> Thanks for the feedback!
> >>> And yes, this will also be important for ConfigJSR (and later mp-config
> >> as
> >>> well).
> >>>
> >>>
> >>>> First it's all about config, so maybe having a method name "diff" is
> >>>> enough. No need for "diffConfig".
> >>>
> >>> Well, diff alone is imo a bit too short as it doesn't have any context
> >>> about what to diff.
> >>> Thus I'd prefer diffConfig.
> >>>
> >>>
> >>>> Some values may have been updated, some might have been deleted and
> >> some
> >>>> other added.
> >>>> Returning a set might not be enough, isn't it?
> >>>
> >>> We really only need the property names which got changed:
> >>> * new ones
> >>> * deleted ones
> >>> * the ones with different values
> >>>
> >>> So a Set is fine.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >>>> Am 05.06.2018 um 08:59 schrieb Jean-Louis MONTEIRO <
> jeano...@gmail.com
> >>> :
> >>>>
> >>>> Few thoughts ...
> >>>>
> >>>> I did not follow really deltaspike to be honest, but I do follow
> >>> MP-Config
> >>>> for instance.
> >>>>
> >>>> First it's all about config, so maybe having a method name "diff" is
> >>>> enough. No need for "diffConfig".
> >>>>
> >>>> Some v

Re: where to place a Config-Diff algorigthm

[Romain Manni-Bucau]

Hmm, maybe too early so don't hesitate to shout if studid: why not having a
config manager sources can register in it and if this manager has >= 1
source then the thread is active otherwise it is destroyed
(running.set(false))
The source would be able to pass its refresh logic (as a function more or
less) the thread will execute in a safe manner (if fail - log but dont quit
the loop) and it returns a boolean to ask to propagate changes upstream or
not.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 5 juin 2018 à 09:23, Jean-Louis MONTEIRO  a
écrit :

> >> Some values may have been updated, some might have been deleted and some
> >> other added.
> >> Returning a set might not be enough, isn't it?
>
> >We really only need the property names which got changed:
> >* new ones
> >* deleted ones
> >* the ones with different values
> >
> >So a Set is fine.
>
> The thing is that you will get the key of everything that changed which
> requires to invalidate the cache for all entries (lock?).
> Or you would need to iterate all the keys, compare again old/new and delete
> entries from cache, do nothing for add (? they will be lazily added during
> lookup maybe) and invalidate the updated values.
>
> That seems to be heavy to handle for nothing has during compare we have all
> information already.
>
>
>
> Le mar. 5 juin 2018 à 09:10, Mark Struberg  a
> écrit :
>
> > Hi JL!
> >
> > Thanks for the feedback!
> > And yes, this will also be important for ConfigJSR (and later mp-config
> as
> > well).
> >
> >
> > > First it's all about config, so maybe having a method name "diff" is
> > > enough. No need for "diffConfig".
> >
> > Well, diff alone is imo a bit too short as it doesn't have any context
> > about what to diff.
> > Thus I'd prefer diffConfig.
> >
> >
> > > Some values may have been updated, some might have been deleted and
> some
> > > other added.
> > > Returning a set might not be enough, isn't it?
> >
> > We really only need the property names which got changed:
> > * new ones
> > * deleted ones
> > * the ones with different values
> >
> > So a Set is fine.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 05.06.2018 um 08:59 schrieb Jean-Louis MONTEIRO  >:
> > >
> > > Few thoughts ...
> > >
> > > I did not follow really deltaspike to be honest, but I do follow
> > MP-Config
> > > for instance.
> > >
> > > First it's all about config, so maybe having a method name "diff" is
> > > enough. No need for "diffConfig".
> > >
> > > Some values may have been updated, some might have been deleted and
> some
> > > other added.
> > > Returning a set might not be enough, isn't it?
> > >
> > > Jean-Louis
> > >
> > >
> > >
> > >
> > >
> > >
> > > Le mar. 5 juin 2018 à 08:55, Mark Struberg 
> a
> > > écrit :
> > >
> > >> Hi folks!
> > >>
> > >> For the new DS-1.9 feature to 'push' config changes we need an
> algorithm
> > >> to detect whether an old and a new config differs.
> > >>
> > >> The signature would be something like:
> > >>
> > >> /**
> > >> *
> > >> * A Set of all the attributes which differ between the old and new
> > config
> > >> Map. An empty Set if there is no difference.
> > >> */
> > >> public Set diffConfig(Map oldValues,
> Map > >> String> newValues)
> > >>
> > >> This is intended for e.g. background threads which read from a
> database
> > >> once per second and compare the old values with the new ones.
> > >> If there was any difference then the set of attributes get reported
> back
> > >> to the Config (which in turn clears the caches, etc).
> > >>
> > >>
> > >> Now where to put this method?
> > >>
> > >> My candidate would be
> > >> org.apache.deltaspike.core.api.config.ConfigResolver.ConfigProvider
> > >> I do not want to put it into the Config interface itself because it is
> > not
> > >> a user contract thingy.
> > >> And I also do not want to put it into ConfigResolver becasue I'd like
> to
> > >> have the impl only available internally and not bloat the
> ConfigResolver
> > >> any further.
> > >>
> > >> Wdyt?
> > >>
> > >> LieGrue,
> > >> strub
> >
> >
>

Re: where to place a Config-Diff algorigthm

[Romain Manni-Bucau]

Hi Mark,

Personally I see it as an internal of a source which fakes to be a map but
is actually key based (= not able to load all values up to date at once
like a database)
so i'm tempted to say we should do like for EE projects and create a
config-source module with all the utilities for users in a portable way
(today a user requires to use impl which is not as clean as we are normally
since it mixes extensible classes by users and internals).

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 5 juin 2018 à 09:00, Jean-Louis MONTEIRO  a
écrit :

> Few thoughts ...
>
> I did not follow really deltaspike to be honest, but I do follow MP-Config
> for instance.
>
> First it's all about config, so maybe having a method name "diff" is
> enough. No need for "diffConfig".
>
> Some values may have been updated, some might have been deleted and some
> other added.
> Returning a set might not be enough, isn't it?
>
> Jean-Louis
>
>
>
>
>
>
> Le mar. 5 juin 2018 à 08:55, Mark Struberg  a
> écrit :
>
> > Hi folks!
> >
> > For the new DS-1.9 feature to 'push' config changes we need an algorithm
> > to detect whether an old and a new config differs.
> >
> > The signature would be something like:
> >
> > /**
> >  *
> >  * A Set of all the attributes which differ between the old and new
> config
> > Map. An empty Set if there is no difference.
> >  */
> > public Set diffConfig(Map oldValues, Map > String> newValues)
> >
> > This is intended for e.g. background threads which read from a database
> > once per second and compare the old values with the new ones.
> > If there was any difference then the set of attributes get reported back
> > to the Config (which in turn clears the caches, etc).
> >
> >
> > Now where to put this method?
> >
> > My candidate would be
> > org.apache.deltaspike.core.api.config.ConfigResolver.ConfigProvider
> > I do not want to put it into the Config interface itself because it is
> not
> > a user contract thingy.
> > And I also do not want to put it into ConfigResolver becasue I'd like to
> > have the impl only available internally and not bloat the ConfigResolver
> > any further.
> >
> > Wdyt?
> >
> > LieGrue,
> > strub
>

Re: Bug in comparator of ConfigSource

[Romain Manni-Bucau]

Hi Marc

You are right, do you want to submit a PR or patch?

Romain


Le mar. 29 mai 2018 20:43, Marc Schorderet  a
écrit :

> Hi guys,
>
>
>
> Today I found an issue by adding one more configuration file for my
> application. We are using version 1.8.0.
>
>
>
> It seems that your comparator of ConfigSource only returns -1 and 1; never
> 0. So, when two config files have the same original, the application
> crashes. We have some common configuration files that are not managed by
> myself, so I cannot guarantee that the original is unique. But I can
> guarantee that original is unique for each application domain, so we have
> never issues with priority.
>
>
>
> private static ConfigSource[] sortDescending(List
> configSources)
> {
> Collections.*sort*(configSources, new Comparator()
> {
>
>
>
> */**  * {@inheritDoc}  */ *@Override
> public int compare(ConfigSource configSource1, ConfigSource
> configSource2)
> {
> return (configSource1.getOrdinal() >
> configSource2.getOrdinal()) ? -1 : 1;
> }
> });
> return configSources.toArray(new ConfigSource[configSources.size()]);
> }
>
> private static List sortAscending(List
> configSources)
> {
> Collections.*sort*(configSources, new Comparator()
> {
>
>
>
> */**  * {@inheritDoc}  */ *@Override
> public int compare(ConfigSource configSource1, ConfigSource
> configSource2)
> {
> return (configSource1.getOrdinal() >
> configSource2.getOrdinal()) ? 1 : -1;
> }
> });
> return configSources;
> }
>
>
>
> When we use the Collection.sort with default TimSort algorithm, Java throws
> a "Comparison method violates its general contract!" Exception. Is it not
> better to use default comparator of integer in this case?
>
>
>
> Thanks,
> Marc
>
>
> --
> Schorderet Marc
> marc.schorde...@gmail.com
>

Re: Next stop 1.9.0 ;)

[Romain Manni-Bucau]

Oh I see, +1 then

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 22 mai 2018 à 11:59, Mark Struberg  a
écrit :

> yes, config got quite some improvements.
>
> LieGrue,
> strub
>
>
> > Am 22.05.2018 um 11:29 schrieb Romain Manni-Bucau  >:
> >
> > Hi Mark,
> >
> > Do we have any new feature compared to 1.8.2 to put in?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mar. 22 mai 2018 à 06:32, Mark Struberg  a
> > écrit :
> >
> >> Hi folks!
> >>
> >> I'd like to work towards a 1.9.0 release.
> >>
> >> Is there anything which we really need in 1.9.0 to be fixed before we
> >> start a release?
> >> Plus, is there anything from 1.8.1 which is not yet in 1.9.0? (don't
> think
> >> so, but asking to be sure).
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>
>
>

Re: Next stop 1.9.0 ;)

[Romain Manni-Bucau]

Hi Mark,

Do we have any new feature compared to 1.8.2 to put in?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le mar. 22 mai 2018 à 06:32, Mark Struberg  a
écrit :

> Hi folks!
>
> I'd like to work towards a 1.9.0 release.
>
> Is there anything which we really need in 1.9.0 to be fixed before we
> start a release?
> Plus, is there anything from 1.8.1 which is not yet in 1.9.0? (don't think
> so, but asking to be sure).
>
> txs and LieGrue,
> strub
>
>

[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482847#comment-16482847
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1345:


[~gpetracek] hmm, why can't we use the same evaluation than in security module 
but triggered by javax.security annotation? We would have an event which would 
set if we are allowed or not and [~princemtl] would observe it and use the 
request to evaluate it. That's what I had in mind. Providing a default impl 
using the request would not be as useful as just handling the interceptor and 
preprocess roles etc from a standard API automatically IMO (secural contexts 
wouldn't be handled based on the cdi request).

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (DELTASPIKE-1345) Support JavaEE Security annotation

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16481990#comment-16481990
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1345:


+1 to have this feature but 1. Not activated by default 2. Abstracted at the 
role evaluation (not assume request is the source of truth all the time).

 

 

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DELTASPIKE-1345) Support JavaEE Security annotation

[Romain Manni-Bucau (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Manni-Bucau updated DELTASPIKE-1345:
---
Priority: Minor  (was: Blocker)

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Minor
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (DELTASPIKE-1345) Support JavaEE Security annotation

[Romain Manni-Bucau (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Manni-Bucau updated DELTASPIKE-1345:
---
Priority: Blocker  (was: Major)

> Support JavaEE Security annotation
> --
>
> Key: DELTASPIKE-1345
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1345
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Security-Module
>Reporter: Jonathan Laterreur
>Priority: Blocker
>
> Deltaspike should take care of the standard JavaEE security annotation.
> {code:java}
> @RolesAllowed
> @PermitAll
> @DenyAll
> {code}
> Maybe a default interceptor should do the job.
> I did something like this (does not covers everything)
> {code:java}
> @Interceptor
> @RolesSecured
> public class RolesSecuredInterceptor {
> private static final Logger LOGGER = 
> LoggerFactory.getLogger(RolesSecuredInterceptor.class);
> @Inject
> private HttpServletRequest request;
> @AroundInvoke
> public Object intercept(InvocationContext ctx) throws Exception {
> boolean allowed = ctx.getMethod().getAnnotation(PermitAll.class) != 
> null;
> if (!allowed) {
> RolesAllowed rolesAllowed = 
> ctx.getMethod().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> }
> if (!allowed) {
> allowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(PermitAll.class) != null;
> if (!allowed) {
> rolesAllowed = 
> ctx.getMethod().getDeclaringClass().getAnnotation(RolesAllowed.class);
> if (rolesAllowed != null) {
> allowed = verifyRolesAllowed(rolesAllowed);
> } else {
> allowed = true;
> }
> }
> }
> }
> if (!allowed) {
> LOGGER.error("Utilisateur « {} » ne possede pas les droits pour 
> appeler cette fonction « {} »", request.getUserPrincipal() != null ? 
> request.getUserPrincipal().getName() : "anonyme",
> ctx.getMethod().getName());
> throw new SecurityException("Ne possede pas les droits pour 
> appeler ce bean CDI");
> }
> return ctx.proceed();
> }
> private boolean verifyRolesAllowed(RolesAllowed rolesAllowed) {
> boolean allowed = false;
> if (request.getUserPrincipal() != null) {
> String[] roles = rolesAllowed.value();
> for (String role : roles) {
> allowed = request.isUserInRole(role);
> if (allowed) {
> break;
> }
> }
> }
> return allowed;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache DeltaSpike-1.8.2

[Romain Manni-Bucau]

+1

Le mer. 16 mai 2018 00:11, Daniel Cunha  a écrit :

> +1
>
> On Tue, May 15, 2018, 18:36 Gerhard Petracek  wrote:
>
> > +1
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2018-05-15 23:26 GMT+02:00 Mark Struberg :
> >
> > > Hi lords and ladies!
> > >
> > > I would like to call a VOTE on releasing Apache DeltaSpike-1.8.2.
> > > This is a maintenance release with java6 compatibility.
> > >
> > > The following tickets got resolved:
> > >
> > > Bug
> > >
> > > [DELTASPIKE-1276] - Multiple license headers
> > > [DELTASPIKE-1299] - Order by items are applied in alphabetic order
> > > [DELTASPIKE-1310] - Please use https (SSL) for links to KEYS,
> hashes,
> > > sigs
> > > [DELTASPIKE-1313] - DeltaSpikeProxyInterceptorLookup fails on WAS
> > > [DELTASPIKE-1316] - add dynamic annotations feature, configurable
> via
> > > config
> > > [DELTASPIKE-1317] - AnnotatedCallableImpl blows up with
> > > ArrayOutofBounds when parsing enums
> > > [DELTASPIKE-1344] - deltaspike-cdictrl-owb has a transient runtime
> > > dependency on Shrinkwrap and Arquillian
> > >
> > > New Feature
> > >
> > > [DELTASPIKE-1319] - labeled alternatives
> > > [DELTASPIKE-1320] - global alternative spi to support custom
> > > (type-safe) mechanisms
> > > [DELTASPIKE-1337] - optional ClassFilter spi
> > > [DELTASPIKE-1338] - support class-filter per test
> > >
> > > Improvement
> > >
> > > [DELTASPIKE-1309] - Upgrade ASM
> > > [DELTASPIKE-1311] - Allow Excluded Repositories
> > > [DELTASPIKE-1329] - ProjectStageProducer should log changed values
> > > [DELTASPIKE-1331] - minor type improvement of the ViewConfigNode
> spi
> > > [DELTASPIKE-1332] - support further cases for custom view-meta-data
> > > [DELTASPIKE-1334] - javadoc for
> ConfigPreProcessor#beforeAddToConfig
> > > [DELTASPIKE-1339] - Add support for dynamic interceptor binding,
> > added
> > > via Extension
> > >
> > > Task
> > >
> > > [DELTASPIKE-1257] - Research why BOM isn't working right in a
> release
> > > [DELTASPIKE-1312] - Upgrade to quartz-2.3.0
> > >
> > >
> > > Here is the staging repo:
> > > https://repository.apache.org/content/repositories/
> > > orgapachedeltaspike-1047/
> > >
> > > The source zip can be found at
> > > https://repository.apache.org/content/repositories/
> > > orgapachedeltaspike-1047/org/apache/deltaspike/deltaspike/1.8.2/
> > > sha1 is add349e89314d9384dc9dc08772af275048343ba
> > >
> > > Please VOTE:
> > >
> > > [+1] yes, ship it
> > > [+0] meh, don't care
> > > [-1] stop there is a ${showstopper}
> > >
> > > The VOTE is open for 72h
> > >
> > > txs and LieGrue,
> > > strub
> > >
> > >
> >
>

Re: InterceptorStrategy?

[Romain Manni-Bucau]

2018-04-27 11:57 GMT+02:00 Mark Struberg :

> Even then we will not be able to change it.
>
> Many customer projects did extend our default InterceptorStrategies with
> their own logic by @Specializes the DS versions.
> Tbh, I also don't see any real benefit from moving to custom Beans instead
> of easy to understand @InterceptorBinding.
>

It requires work for us to load an implem dynamically even when we'll never
change the impl,
it makes it hard to understand from a design perspective for end users
cause it is not aligned on CDI,
it is an API so as an user you expect to implement it whereas you never do
it normally

So overall it is more confusing for CDI users than helping and encourages
to bypass CDI for part of the IoC which sounds very nasty.


>
> LieGrue,
> strub
>
> > Am 27.04.2018 um 09:27 schrieb Romain Manni-Bucau  >:
> >
> > Ok so we are back on the compatibility constraint right?
> > Do we have a clear view on this line? (like the list of impl not
> supporting
> > it?)
> > If yes we can see when dropping it is possible.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
> >
> > 2018-04-27 9:04 GMT+02:00 Mark Struberg :
> >
> >> In theory you are right.
> >>
> >> But adding an Interceptor Bean is WAY more work than having a
> standard
> >> @InterceptorBinding.
> >> And it also created lots of compatibility issues with older containers.
> >> Wheras @InterceptorBinding works everywhere.
> >>
> >> LieGrue,
> >> strub
> >>
> >>> Am 27.04.2018 um 08:51 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> 2018-04-27 8:38 GMT+02:00 Mark Struberg :
> >>>
> >>>> No, it's not reinventing the wheel because those parts are missing in
> >> the
> >>>> CDI spec.
> >>>>
> >>>> The point is to keep the same  but you can switch
> >> the
> >>>> actual behaviour purely via config.
> >>>> That way we don't need to change the beans.xml content for switching
> >> e.g.
> >>>> between resource_local and UserTransaction handling for
> @Transactional.
> >>>>
> >>>> And this is important because otherwise users would need to re-package
> >>>> deltaspike jars :(
> >>>>
> >>>> So no, there is imo no way to do the same functionality in CDI - not
> >> even
> >>>> CDI-2.0
> >>>>
> >>>
> >>> Hmm, don't we do do it since cdi 1.0 (I ack it can be in late impl
> >>> versions).
> >>> An extension is perfectly able to do that since you can add the
> >> interceptor
> >>> programmatically when needed and select the impl at the same time, no?
> >>> I don't see the blocker we would have.
> >>>
> >>>
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>
> >>>>> Am 26.04.2018 um 07:16 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> >>>>> :
> >>>>>
> >>>>> there are 2 issues:
> >>>>>
> >>>>> 1. we reinvent the wheel and do a competitive API compared to CDI
> >>>>> 2. most of them - except maybe tx one - will never be implemented by
> >> any
> >>>>> user
> >>>>>
> >>>>> So we kind of encourage users to do it wrong.
> >>>>>
> >>>>> Always thought it was technical workarounds so now we are in 2018 I
> >> think
> >>>>> we can slowly hide it or even drop it when not relevant (all core
> >>>>> interceptors pby)
> >>>>>
> >>>>>
> >>>>>
> >>>>> Romain Manni-Bucau
> >>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >>>> rm

Re: InterceptorStrategy?

[Romain Manni-Bucau]

Ok so we are back on the compatibility constraint right?
Do we have a clear view on this line? (like the list of impl not supporting
it?)
If yes we can see when dropping it is possible.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-27 9:04 GMT+02:00 Mark Struberg :

> In theory you are right.
>
> But adding an Interceptor Bean is WAY more work than having a standard
> @InterceptorBinding.
> And it also created lots of compatibility issues with older containers.
> Wheras @InterceptorBinding works everywhere.
>
> LieGrue,
> strub
>
> > Am 27.04.2018 um 08:51 schrieb Romain Manni-Bucau  >:
> >
> > 2018-04-27 8:38 GMT+02:00 Mark Struberg :
> >
> >> No, it's not reinventing the wheel because those parts are missing in
> the
> >> CDI spec.
> >>
> >> The point is to keep the same  but you can switch
> the
> >> actual behaviour purely via config.
> >> That way we don't need to change the beans.xml content for switching
> e.g.
> >> between resource_local and UserTransaction handling for @Transactional.
> >>
> >> And this is important because otherwise users would need to re-package
> >> deltaspike jars :(
> >>
> >> So no, there is imo no way to do the same functionality in CDI - not
> even
> >> CDI-2.0
> >>
> >
> > Hmm, don't we do do it since cdi 1.0 (I ack it can be in late impl
> > versions).
> > An extension is perfectly able to do that since you can add the
> interceptor
> > programmatically when needed and select the impl at the same time, no?
> > I don't see the blocker we would have.
> >
> >
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 26.04.2018 um 07:16 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> there are 2 issues:
> >>>
> >>> 1. we reinvent the wheel and do a competitive API compared to CDI
> >>> 2. most of them - except maybe tx one - will never be implemented by
> any
> >>> user
> >>>
> >>> So we kind of encourage users to do it wrong.
> >>>
> >>> Always thought it was technical workarounds so now we are in 2018 I
> think
> >>> we can slowly hide it or even drop it when not relevant (all core
> >>> interceptors pby)
> >>>
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >> rmannibucau> |
> >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>> <https://www.packtpub.com/application-development/java-
> >> ee-8-high-performance>
> >>>
> >>> 2018-04-26 7:06 GMT+02:00 Gerhard Petracek :
> >>>
> >>>> the concrete interceptor-strategies (like TransactionStrategy) are
> part
> >> of
> >>>> our spi. your suggestion would mean that we would need to move them as
> >> well
> >>>> (= remove them from the spi).
> >>>> def. -1 for that because i know several users who are using them.
> >>>> i really don't get the issue you have with a simple marker interface
> >> (after
> >>>> we have it for 7 years - including codi).
> >>>>
> >>>> btw. there are users out there who re-use InterceptorStrategy for
> their
> >>>> internal interceptor-strategies (of their own libs).
> >>>>
> >>>> regards,
> >>>> gerhard
> >>>>
> >>>>
> >>>>
> >>>> 2018-04-26 6:41 GMT+02:00 Romain Manni-Bucau :
> >>>>
> >>>>> Still means it doesnt have to be in the API right?
> >>>>>
> >>>>> Le 26 avr. 2018 00:44, "Gerhard Petracek"  a
> >>>> écrit :
> >>>>>
> >>>>>> #1 with cdi 1.0 (or to be more concrete: owb for cdi 1.0) you can't
> >> get
> >>>>> rid
> >&

Re: InterceptorStrategy?

[Romain Manni-Bucau]

2018-04-27 8:38 GMT+02:00 Mark Struberg :

> No, it's not reinventing the wheel because those parts are missing in the
> CDI spec.
>
> The point is to keep the same  but you can switch the
> actual behaviour purely via config.
> That way we don't need to change the beans.xml content for switching e.g.
> between resource_local and UserTransaction handling for @Transactional.
>
> And this is important because otherwise users would need to re-package
> deltaspike jars :(
>
> So no, there is imo no way to do the same functionality in CDI - not even
> CDI-2.0
>

Hmm, don't we do do it since cdi 1.0 (I ack it can be in late impl
versions).
An extension is perfectly able to do that since you can add the interceptor
programmatically when needed and select the impl at the same time, no?
I don't see the blocker we would have.


>
> LieGrue,
> strub
>
>
>
> > Am 26.04.2018 um 07:16 schrieb Romain Manni-Bucau  >:
> >
> > there are 2 issues:
> >
> > 1. we reinvent the wheel and do a competitive API compared to CDI
> > 2. most of them - except maybe tx one - will never be implemented by any
> > user
> >
> > So we kind of encourage users to do it wrong.
> >
> > Always thought it was technical workarounds so now we are in 2018 I think
> > we can slowly hide it or even drop it when not relevant (all core
> > interceptors pby)
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
> >
> > 2018-04-26 7:06 GMT+02:00 Gerhard Petracek :
> >
> >> the concrete interceptor-strategies (like TransactionStrategy) are part
> of
> >> our spi. your suggestion would mean that we would need to move them as
> well
> >> (= remove them from the spi).
> >> def. -1 for that because i know several users who are using them.
> >> i really don't get the issue you have with a simple marker interface
> (after
> >> we have it for 7 years - including codi).
> >>
> >> btw. there are users out there who re-use InterceptorStrategy for their
> >> internal interceptor-strategies (of their own libs).
> >>
> >> regards,
> >> gerhard
> >>
> >>
> >>
> >> 2018-04-26 6:41 GMT+02:00 Romain Manni-Bucau :
> >>
> >>> Still means it doesnt have to be in the API right?
> >>>
> >>> Le 26 avr. 2018 00:44, "Gerhard Petracek"  a
> >> écrit :
> >>>
> >>>> #1 with cdi 1.0 (or to be more concrete: owb for cdi 1.0) you can't
> get
> >>> rid
> >>>> of pre-configured interceptors (that's why we introduced the
> >>>> interceptor-strategy concept initially).
> >>>> #2 e.g. TransactionStrategy has benefits beyond that (a public example
> >> is
> >>>> the usage in the ds-data-module)
> >>>>
> >>>> regards,
> >>>> gerhard
> >>>>
> >>>>
> >>>>
> >>>> 2018-04-25 6:58 GMT+02:00 Romain Manni-Bucau :
> >>>>
> >>>>> I get it but it means we add a layer on top of interceptor for
> >>>>> pluggability. This is actually built in in CDI so not really needed.
> >>>>>
> >>>>> Also the hierarchy point is fine but should be per type of strategy
> >> and
> >>>>> therefore we dont need a generic one in the api.
> >>>>>
> >>>>> As a user if i use DS and an interceptor, do i need to impl this
> >> public
> >>>>> api? Never normally so this sounds more misleading or reinventing the
> >>>> wheel
> >>>>> than anything else for me.
> >>>>>
> >>>>> That said we can move it in our impl modules to keep the feature but
> >>>> still
> >>>>> a clean api.
> >>>>>
> >>>>> Le 24 avr. 2018 23:21, "Gerhard Petracek"  a
> >>>> écrit :
> >>>>>
> >>>>>> a concrete example:
> >>>>>> @Transactional
> >>>>>>
> >>>>>> ->
> >>>>>>

Re: InterceptorStrategy?

[Romain Manni-Bucau]

oki, let's do that.

Thanks Gerhard for the story behind that part of our code.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-26 7:36 GMT+02:00 Gerhard Petracek :

> imo we can re-visit the topic once we have cdi 1.1+ as our baseline,
> because with cdi 1.0 it's def. needed.
>
> regards,
> gerhard
>
>
>
> 2018-04-26 7:16 GMT+02:00 Romain Manni-Bucau :
>
> > there are 2 issues:
> >
> > 1. we reinvent the wheel and do a competitive API compared to CDI
> > 2. most of them - except maybe tx one - will never be implemented by any
> > user
> >
> > So we kind of encourage users to do it wrong.
> >
> > Always thought it was technical workarounds so now we are in 2018 I think
> > we can slowly hide it or even drop it when not relevant (all core
> > interceptors pby)
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-
> > ee-8-high-performance>
> >
> > 2018-04-26 7:06 GMT+02:00 Gerhard Petracek :
> >
> > > the concrete interceptor-strategies (like TransactionStrategy) are part
> > of
> > > our spi. your suggestion would mean that we would need to move them as
> > well
> > > (= remove them from the spi).
> > > def. -1 for that because i know several users who are using them.
> > > i really don't get the issue you have with a simple marker interface
> > (after
> > > we have it for 7 years - including codi).
> > >
> > > btw. there are users out there who re-use InterceptorStrategy for their
> > > internal interceptor-strategies (of their own libs).
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2018-04-26 6:41 GMT+02:00 Romain Manni-Bucau :
> > >
> > > > Still means it doesnt have to be in the API right?
> > > >
> > > > Le 26 avr. 2018 00:44, "Gerhard Petracek"  a
> > > écrit :
> > > >
> > > > > #1 with cdi 1.0 (or to be more concrete: owb for cdi 1.0) you can't
> > get
> > > > rid
> > > > > of pre-configured interceptors (that's why we introduced the
> > > > > interceptor-strategy concept initially).
> > > > > #2 e.g. TransactionStrategy has benefits beyond that (a public
> > example
> > > is
> > > > > the usage in the ds-data-module)
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > >
> > > > >
> > > > > 2018-04-25 6:58 GMT+02:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > > > >
> > > > > > I get it but it means we add a layer on top of interceptor for
> > > > > > pluggability. This is actually built in in CDI so not really
> > needed.
> > > > > >
> > > > > > Also the hierarchy point is fine but should be per type of
> strategy
> > > and
> > > > > > therefore we dont need a generic one in the api.
> > > > > >
> > > > > > As a user if i use DS and an interceptor, do i need to impl this
> > > public
> > > > > > api? Never normally so this sounds more misleading or reinventing
> > the
> > > > > wheel
> > > > > > than anything else for me.
> > > > > >
> > > > > > That said we can move it in our impl modules to keep the feature
> > but
> > > > > still
> > > > > > a clean api.
> > > > > >
> > > > > > Le 24 avr. 2018 23:21, "Gerhard Petracek" 
> a
> > > > > écrit :
> > > > > >
> > > > > > > a concrete example:
> > > > > > > @Transactional
> > > > > > >
> > > > > > > ->
> > 

Re: InterceptorStrategy?

[Romain Manni-Bucau]

there are 2 issues:

1. we reinvent the wheel and do a competitive API compared to CDI
2. most of them - except maybe tx one - will never be implemented by any
user

So we kind of encourage users to do it wrong.

Always thought it was technical workarounds so now we are in 2018 I think
we can slowly hide it or even drop it when not relevant (all core
interceptors pby)



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-26 7:06 GMT+02:00 Gerhard Petracek :

> the concrete interceptor-strategies (like TransactionStrategy) are part of
> our spi. your suggestion would mean that we would need to move them as well
> (= remove them from the spi).
> def. -1 for that because i know several users who are using them.
> i really don't get the issue you have with a simple marker interface (after
> we have it for 7 years - including codi).
>
> btw. there are users out there who re-use InterceptorStrategy for their
> internal interceptor-strategies (of their own libs).
>
> regards,
> gerhard
>
>
>
> 2018-04-26 6:41 GMT+02:00 Romain Manni-Bucau :
>
> > Still means it doesnt have to be in the API right?
> >
> > Le 26 avr. 2018 00:44, "Gerhard Petracek"  a
> écrit :
> >
> > > #1 with cdi 1.0 (or to be more concrete: owb for cdi 1.0) you can't get
> > rid
> > > of pre-configured interceptors (that's why we introduced the
> > > interceptor-strategy concept initially).
> > > #2 e.g. TransactionStrategy has benefits beyond that (a public example
> is
> > > the usage in the ds-data-module)
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2018-04-25 6:58 GMT+02:00 Romain Manni-Bucau :
> > >
> > > > I get it but it means we add a layer on top of interceptor for
> > > > pluggability. This is actually built in in CDI so not really needed.
> > > >
> > > > Also the hierarchy point is fine but should be per type of strategy
> and
> > > > therefore we dont need a generic one in the api.
> > > >
> > > > As a user if i use DS and an interceptor, do i need to impl this
> public
> > > > api? Never normally so this sounds more misleading or reinventing the
> > > wheel
> > > > than anything else for me.
> > > >
> > > > That said we can move it in our impl modules to keep the feature but
> > > still
> > > > a clean api.
> > > >
> > > > Le 24 avr. 2018 23:21, "Gerhard Petracek"  a
> > > écrit :
> > > >
> > > > > a concrete example:
> > > > > @Transactional
> > > > >
> > > > > ->
> > > > > @Interceptor is on TransactionalInterceptor whereas
> > InterceptorStrategy
> > > > is
> > > > > the marker interface for the strategies (and not the interceptor) -
> > in
> > > > this
> > > > > case TransactionStrategy.
> > > > >
> > > > > (to quickly get an overview of all interceptor-strategies you just
> > need
> > > > to
> > > > > open the hierarchy-view for InterceptorStrategy and you have
> > everything
> > > > you
> > > > > need with one step...)
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > >
> > > > >
> > > > > 2018-04-24 22:35 GMT+02:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > > > >
> > > > > > Hmm not sure i get it, annotations are hard to browse in IDE? Is
> it
> > > > what
> > > > > it
> > > > > > addresses?
> > > > > >
> > > > > > Le 24 avr. 2018 21:10, "Gerhard Petracek" 
> a
> > > > > écrit :
> > > > > >
> > > > > > > hi romain,
> > > > > > >
> > > > > > > not really. 1 interceptor could have n strategies as candidates
> > > (e.g.
> > > > > see
> > > > > > > TransactionStrategy for which we provide multiple
> implementations
> > > > > > > out-of-t

Re: InterceptorStrategy?

[Romain Manni-Bucau]

Still means it doesnt have to be in the API right?

Le 26 avr. 2018 00:44, "Gerhard Petracek"  a écrit :

> #1 with cdi 1.0 (or to be more concrete: owb for cdi 1.0) you can't get rid
> of pre-configured interceptors (that's why we introduced the
> interceptor-strategy concept initially).
> #2 e.g. TransactionStrategy has benefits beyond that (a public example is
> the usage in the ds-data-module)
>
> regards,
> gerhard
>
>
>
> 2018-04-25 6:58 GMT+02:00 Romain Manni-Bucau :
>
> > I get it but it means we add a layer on top of interceptor for
> > pluggability. This is actually built in in CDI so not really needed.
> >
> > Also the hierarchy point is fine but should be per type of strategy and
> > therefore we dont need a generic one in the api.
> >
> > As a user if i use DS and an interceptor, do i need to impl this public
> > api? Never normally so this sounds more misleading or reinventing the
> wheel
> > than anything else for me.
> >
> > That said we can move it in our impl modules to keep the feature but
> still
> > a clean api.
> >
> > Le 24 avr. 2018 23:21, "Gerhard Petracek"  a
> écrit :
> >
> > > a concrete example:
> > > @Transactional
> > >
> > > ->
> > > @Interceptor is on TransactionalInterceptor whereas InterceptorStrategy
> > is
> > > the marker interface for the strategies (and not the interceptor) - in
> > this
> > > case TransactionStrategy.
> > >
> > > (to quickly get an overview of all interceptor-strategies you just need
> > to
> > > open the hierarchy-view for InterceptorStrategy and you have everything
> > you
> > > need with one step...)
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2018-04-24 22:35 GMT+02:00 Romain Manni-Bucau :
> > >
> > > > Hmm not sure i get it, annotations are hard to browse in IDE? Is it
> > what
> > > it
> > > > addresses?
> > > >
> > > > Le 24 avr. 2018 21:10, "Gerhard Petracek"  a
> > > écrit :
> > > >
> > > > > hi romain,
> > > > >
> > > > > not really. 1 interceptor could have n strategies as candidates
> (e.g.
> > > see
> > > > > TransactionStrategy for which we provide multiple implementations
> > > > > out-of-the-box).
> > > > > that's the whole concept. the marker interfaces is just to find all
> > > > > strategies in a project easily.
> > > > > we have it since 02/2011 (back then it was  codi) and a lot of
> users
> > > are
> > > > > using it (during the dev. process) and i haven't heard about any
> > > concern
> > > > > (from users).
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > >
> > > > >
> > > > > 2018-04-24 19:31 GMT+02:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > > > >
> > > > > > Le 24 avr. 2018 19:18, "Gerhard Petracek" 
> a
> > > > > écrit :
> > > > > >
> > > > > >  it was always just a marker-interface to list all
> > > > interceptor-strategies
> > > > > > easily.
> > > > > >
> > > > > >
> > > > > > But if it is just interceptors, doesnt @Interceptor fulfills that
> > > > > already?
> > > > > >
> > > > > > My only concern is exposing it in api to user where it is
> actually
> > a
> > > > dead
> > > > > > interface.
> > > > > >
> > > > > >
> > > > > > regards,
> > > > > > gerhard
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2018-04-24 13:47 GMT+02:00 Thomas Andraschko <
> > > > > andraschko.tho...@gmail.com
> > > > > > >:
> > > > > >
> > > > > > > basically +1
> > > > > > > but its still used currently
> > > > > > >
> > > > > > >
> > > > > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >:
> > > > > > >
> > > > > > > > Hi guys,
> > > > > > > >
> > > > > > > > Do we still need InterceptorStrategy?
> > > > > > > >
> > > > > > > > If not, can we deprecate it and remove it from our built-in
> > > > > > interceptors?
> > > > > > > >
> > > > > > > > Romain Manni-Bucau
> > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/
> > > > > > > > rmannibucau> |
> > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > > <https://www.packtpub.com/application-development/java-
> > > > > > > > ee-8-high-performance>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: InterceptorStrategy?

[Romain Manni-Bucau]

I get it but it means we add a layer on top of interceptor for
pluggability. This is actually built in in CDI so not really needed.

Also the hierarchy point is fine but should be per type of strategy and
therefore we dont need a generic one in the api.

As a user if i use DS and an interceptor, do i need to impl this public
api? Never normally so this sounds more misleading or reinventing the wheel
than anything else for me.

That said we can move it in our impl modules to keep the feature but still
a clean api.

Le 24 avr. 2018 23:21, "Gerhard Petracek"  a écrit :

> a concrete example:
> @Transactional
>
> ->
> @Interceptor is on TransactionalInterceptor whereas InterceptorStrategy is
> the marker interface for the strategies (and not the interceptor) - in this
> case TransactionStrategy.
>
> (to quickly get an overview of all interceptor-strategies you just need to
> open the hierarchy-view for InterceptorStrategy and you have everything you
> need with one step...)
>
> regards,
> gerhard
>
>
>
> 2018-04-24 22:35 GMT+02:00 Romain Manni-Bucau :
>
> > Hmm not sure i get it, annotations are hard to browse in IDE? Is it what
> it
> > addresses?
> >
> > Le 24 avr. 2018 21:10, "Gerhard Petracek"  a
> écrit :
> >
> > > hi romain,
> > >
> > > not really. 1 interceptor could have n strategies as candidates (e.g.
> see
> > > TransactionStrategy for which we provide multiple implementations
> > > out-of-the-box).
> > > that's the whole concept. the marker interfaces is just to find all
> > > strategies in a project easily.
> > > we have it since 02/2011 (back then it was  codi) and a lot of users
> are
> > > using it (during the dev. process) and i haven't heard about any
> concern
> > > (from users).
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2018-04-24 19:31 GMT+02:00 Romain Manni-Bucau :
> > >
> > > > Le 24 avr. 2018 19:18, "Gerhard Petracek"  a
> > > écrit :
> > > >
> > > >  it was always just a marker-interface to list all
> > interceptor-strategies
> > > > easily.
> > > >
> > > >
> > > > But if it is just interceptors, doesnt @Interceptor fulfills that
> > > already?
> > > >
> > > > My only concern is exposing it in api to user where it is actually a
> > dead
> > > > interface.
> > > >
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2018-04-24 13:47 GMT+02:00 Thomas Andraschko <
> > > andraschko.tho...@gmail.com
> > > > >:
> > > >
> > > > > basically +1
> > > > > but its still used currently
> > > > >
> > > > >
> > > > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > > > >
> > > > > > Hi guys,
> > > > > >
> > > > > > Do we still need InterceptorStrategy?
> > > > > >
> > > > > > If not, can we deprecate it and remove it from our built-in
> > > > interceptors?
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > > > rmannibucau> |
> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > <https://www.packtpub.com/application-development/java-
> > > > > > ee-8-high-performance>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: InterceptorStrategy?

[Romain Manni-Bucau]

Hmm not sure i get it, annotations are hard to browse in IDE? Is it what it
addresses?

Le 24 avr. 2018 21:10, "Gerhard Petracek"  a écrit :

> hi romain,
>
> not really. 1 interceptor could have n strategies as candidates (e.g. see
> TransactionStrategy for which we provide multiple implementations
> out-of-the-box).
> that's the whole concept. the marker interfaces is just to find all
> strategies in a project easily.
> we have it since 02/2011 (back then it was  codi) and a lot of users are
> using it (during the dev. process) and i haven't heard about any concern
> (from users).
>
> regards,
> gerhard
>
>
>
> 2018-04-24 19:31 GMT+02:00 Romain Manni-Bucau :
>
> > Le 24 avr. 2018 19:18, "Gerhard Petracek"  a
> écrit :
> >
> >  it was always just a marker-interface to list all interceptor-strategies
> > easily.
> >
> >
> > But if it is just interceptors, doesnt @Interceptor fulfills that
> already?
> >
> > My only concern is exposing it in api to user where it is actually a dead
> > interface.
> >
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2018-04-24 13:47 GMT+02:00 Thomas Andraschko <
> andraschko.tho...@gmail.com
> > >:
> >
> > > basically +1
> > > but its still used currently
> > >
> > >
> > > 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau :
> > >
> > > > Hi guys,
> > > >
> > > > Do we still need InterceptorStrategy?
> > > >
> > > > If not, can we deprecate it and remove it from our built-in
> > interceptors?
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > > > rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <https://www.packtpub.com/application-development/java-
> > > > ee-8-high-performance>
> > > >
> > >
> >
>

Re: InterceptorStrategy?

[Romain Manni-Bucau]

Le 24 avr. 2018 19:18, "Gerhard Petracek"  a écrit :

 it was always just a marker-interface to list all interceptor-strategies
easily.


But if it is just interceptors, doesnt @Interceptor fulfills that already?

My only concern is exposing it in api to user where it is actually a dead
interface.


regards,
gerhard



2018-04-24 13:47 GMT+02:00 Thomas Andraschko :

> basically +1
> but its still used currently
>
>
> 2018-04-23 11:46 GMT+02:00 Romain Manni-Bucau :
>
> > Hi guys,
> >
> > Do we still need InterceptorStrategy?
> >
> > If not, can we deprecate it and remove it from our built-in
interceptors?
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-
> > ee-8-high-performance>
> >
>

InterceptorStrategy?

[Romain Manni-Bucau]

Hi guys,

Do we still need InterceptorStrategy?

If not, can we deprecate it and remove it from our built-in interceptors?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

Re: atomic access to config values

[Romain Manni-Bucau]

2018-04-06 11:11 GMT+02:00 Mark Struberg :

> > 1. don't expose the read side of the API, hide it under our impls
> > (resolver, @configuration, ...)
>
> We will add the feature to @Configuration. That's on our list and doable
> in a perfectly transparent way.
>
> Regarding ConfigResolver. The whole class mainly exists for backward
> compat reasons.
> The only actively used method should be getConfig(). The Config interface
> is the way to go. Thus the functionality only got added there.
>

Good catch, read it as "everywhere" so it includes config


>
>
> > 2. don't use typeresolvers but keys to consider
>
> That's not possible. You need the whole lookup chain information.
> Suffixes, variable replacement etc.
> You simply don't have this information if you only go by the keys.
> That's why your proposed API cannot work.
>

Nop, everything should end up on a key so it must work (or we have a more
vicious issue).
For @Config we can do it automatically as you explained, for other cases
the user will need to do it anyway himself
so having this indirection or not doesn't help much. == it should be fine
and easier for end user to just check keys.


>
>
> > 3. provide a context handler
>
> What do you understand by that?
>


Don't provide a snapshot which allows to read values but something to
decorate a "task" which will set the correct value reader under the hood.
It avoids to have to propagate the snapshot in the whole user codebase
which is a huge breaking change not that justified technically.
It would also mess up all your code if you think about it and reduce the
composability of the modules of an app at scale.


>
> LieGrue,
> strub
>
>
> > Am 06.04.2018 um 10:34 schrieb Romain Manni-Bucau  >:
> >
> > Mark, I started to play with the API you proposed and I'd like to propose
> > this change:
> >
> > 1. don't expose the read side of the API, hide it under our impls
> > (resolver, @configuration, ...)
> > 2. don't use typeresolvers but keys to consider
> > 3. provide a context handler
> >
> > Here is how I would envision it (dont give too much values on the naming)
> >
> > public interface Config { // skipping "old" part
> >FrozenConfigurationValues freeze(String... keys);
> > }
> >
> >
> >
> > public interface FrozenConfigurationValues {
> > T execute(Supplier task);
> > }
> >
> >
> > this part would be in the *api*.
> >
> > Then the impl of FrozenConfigValues would be in -impl module and its
> usage
> > in our resolvers (TypeResolver, ConfigResolvers)+@Configuration which
> would
> > make it transparent for the end user
> > as soon as he wrapped his code execution with the FrozenConfiguration
> > values:
> >
> > final FrozenConfigurationValues fcv = config.freeze("ftp.host",
> > "ftp.port", "ftp.dir", "ftp.user", "ftp.password");
> > fcv.execute(() -> {
> >return *ftp.download(); // uses @Configuration FtpConfiguration*
> > });
> >
> > Advantage is it will allow to use nested "execute" easily and therefore
> > keep the code modular on the user side.
> > We can be fancy and provide a default filter which would take the keys to
> > freeze for each requests in ConfigResolver OOTB if we want but I'm more
> > confident with this kind of design
> > than starting to expose some internals directly.
> >
> > Side note: the fact it provides an execute method is to be compatible
> with
> > reactive programming (async context for servlets for instance) and not
> only
> > synchronous programming.
> >
> > The big gain is the user code does NOT need to be modified to benefit
> from
> > this feature and the setup can be done on top of the app (through a
> filter,
> > interceptor or anything else)
> > which is consistent with the fact you can plug at deploy time some
> sources
> > the dev is not aware off. It means you can dev assuming your config is
> > always consistent (cause
> > you dev with classpath files only) and behave very well at runtime cause
> at
> > deploy time the work has been done without requiring to recode parts of
> the
> > app. In other words
> > we give spaces to dev, devops and ops ;).
> >
> > wdyt?
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.co

Re: atomic access to config values

[Romain Manni-Bucau]

Mark, I started to play with the API you proposed and I'd like to propose
this change:

1. don't expose the read side of the API, hide it under our impls
(resolver, @configuration, ...)
2. don't use typeresolvers but keys to consider
3. provide a context handler

Here is how I would envision it (dont give too much values on the naming)

public interface Config { // skipping "old" part
FrozenConfigurationValues freeze(String... keys);
}



public interface FrozenConfigurationValues {
 T execute(Supplier task);
}


this part would be in the *api*.

Then the impl of FrozenConfigValues would be in -impl module and its usage
in our resolvers (TypeResolver, ConfigResolvers)+@Configuration which would
make it transparent for the end user
as soon as he wrapped his code execution with the FrozenConfiguration
values:

final FrozenConfigurationValues fcv = config.freeze("ftp.host",
"ftp.port", "ftp.dir", "ftp.user", "ftp.password");
fcv.execute(() -> {
return *ftp.download(); // uses @Configuration FtpConfiguration*
});

Advantage is it will allow to use nested "execute" easily and therefore
keep the code modular on the user side.
We can be fancy and provide a default filter which would take the keys to
freeze for each requests in ConfigResolver OOTB if we want but I'm more
confident with this kind of design
than starting to expose some internals directly.

Side note: the fact it provides an execute method is to be compatible with
reactive programming (async context for servlets for instance) and not only
synchronous programming.

The big gain is the user code does NOT need to be modified to benefit from
this feature and the setup can be done on top of the app (through a filter,
interceptor or anything else)
which is consistent with the fact you can plug at deploy time some sources
the dev is not aware off. It means you can dev assuming your config is
always consistent (cause
you dev with classpath files only) and behave very well at runtime cause at
deploy time the work has been done without requiring to recode parts of the
app. In other words
we give spaces to dev, devops and ops ;).

wdyt?



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-06 9:40 GMT+02:00 Romain Manni-Bucau :

> ok ok, i'm fine not having it implementing it - just thought it was not a
> blocker.
>
> Can we get an unwrap in Config *api* to be able to plug features like that
> (which allows us to use it under the hood and when we think it is ready we
> promote it to the api)?
>
> config.unwrap(SnapshotService.class)
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
> 2018-04-06 9:13 GMT+02:00 Mark Struberg :
>
>> But the ConfigTransaction/ConfigSnapshot has only one functionality:
>> getValue().
>> But the Config itself is the underlying infrastructure holder and has
>> tons of features.
>>
>> Having ConfigSnapshot extends Config and just being a 'frozen' Config
>> would mean we would also need to implement all features.
>> And of course also resolve ALL conigured values at this time, and not
>> only the few given ones.
>> I think that is too much.
>>
>> LieGrue,
>> strub
>>
>> > Am 06.04.2018 um 09:08 schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>> >
>> > 2018-04-06 8:51 GMT+02:00 Mark Struberg :
>> >
>> >> Btw, ImmutableConfig would kind of suggest that it extends our Config
>> >> interface, isn't?
>> >>
>> >
>> > Didn't think to that but it would be possible since we snapshot a
>> subconfig
>> > which can be a config. A snapshot sounds like it is the same object type
>> > but "frozen" no?
>> >
>> > Anyway what about making it an internal of ConfigImpl and not a Config
>> > thing, then we don't care much of the name, right?
>> >
>> >
>> >> But that's not the case, it is really something different.
>> >>
>> >> LieGrue,
>> >> strub
>> >>
>>

cipher service rework?

[Romain Manni-Bucau]

Hi guys,

I have a mix of proposal question on our cipher service:

1. why do we have impl details in the api? salt and setter are impl details
no? Also it sounds like a transversal concern of the ciphering by itself so
why not removing it from the API (or deprecating it)

So proposal is to move

public interface CipherService
{
void setMasterHash(String masterPassword, String masterSalt,
boolean overwrite) throws IOException;

String encrypt(String cleartext, String masterSalt);

String decrypt(String encryptedValue, String masterSalt);
}

to

public interface CipherService
{

String encrypt(String cleartext);

String decrypt(String encryptedValue);
}


2. Why isnt it linked to our config? Here is what I'd like (syntax can be
discussed but just want to share the idea/usage):

my.super.config = cipher:thisIsCiphered # default impl
my.super.config = cipher:customCipherServiceAlias:thisIsCiphered # to
support to aggregate configs using different ciphering on the backend


but if i read "my.super.config" I get "this is a super value" for instance.

Technically we can add a default filter probably and support it OOTB pretty
easily, it also enable to support it in the logging automatically to skip
it since ciphered data are by default sensitive data.


Since next release will be 1.9 I think we can clean it up now before it
gets out.

Wdyt?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

Re: atomic access to config values

[Romain Manni-Bucau]

ok ok, i'm fine not having it implementing it - just thought it was not a
blocker.

Can we get an unwrap in Config *api* to be able to plug features like that
(which allows us to use it under the hood and when we think it is ready we
promote it to the api)?

config.unwrap(SnapshotService.class)....


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-06 9:13 GMT+02:00 Mark Struberg :

> But the ConfigTransaction/ConfigSnapshot has only one functionality:
> getValue().
> But the Config itself is the underlying infrastructure holder and has tons
> of features.
>
> Having ConfigSnapshot extends Config and just being a 'frozen' Config
> would mean we would also need to implement all features.
> And of course also resolve ALL conigured values at this time, and not only
> the few given ones.
> I think that is too much.
>
> LieGrue,
> strub
>
> > Am 06.04.2018 um 09:08 schrieb Romain Manni-Bucau  >:
> >
> > 2018-04-06 8:51 GMT+02:00 Mark Struberg :
> >
> >> Btw, ImmutableConfig would kind of suggest that it extends our Config
> >> interface, isn't?
> >>
> >
> > Didn't think to that but it would be possible since we snapshot a
> subconfig
> > which can be a config. A snapshot sounds like it is the same object type
> > but "frozen" no?
> >
> > Anyway what about making it an internal of ConfigImpl and not a Config
> > thing, then we don't care much of the name, right?
> >
> >
> >> But that's not the case, it is really something different.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>> Am 05.04.2018 um 22:02 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> Between the 3 createSnapshot or snapshot.
> >>>
> >>> What about ImmutableConfig and Config.toImmutable(keys)?
> >>>
> >>> Not a big deal though.
> >>>
> >>>
> >>> Le 5 avr. 2018 21:38, "Thomas Andraschko"  >
> >> a
> >>> écrit :
> >>>
> >>> +1 for ConfigSnapshot and Config#snapshot
> >>>
> >>> 2018-04-05 21:32 GMT+02:00 Mark Struberg :
> >>>
> >>>> Had a long discussion with Tomas Langer about atomic access this
> >>> afternoon.
> >>>>
> >>>> What we came up with is probably better than 'ConfigTransaction',
> >> because
> >>>> the 'Transaction' term really creates the wrong impression.
> >>>>
> >>>> So what about
> >>>>
> >>>> * renaming ConfigTransaction to ConfigSnapshot and
> >>>> * Config#createTransation to
> >>>>   - Config#resolveSnapshot or
> >>>>   - Config#createSnapshot, or just
> >>>>   - Config#snapshot ?
> >>>>
> >>>> Any thoughts? Or even any better ideas?
> >>>>
> >>>> txs and LieGrue,
> >>>> strub
> >>>>
> >>>>> Am 05.04.2018 um 10:39 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> >>>>> :
> >>>>>
> >>>>> Yes, you are right, in all cases the source must send an event to the
> >>>>> aggregator (config) to notify it to update its state (timestamp or
> >> not).
> >>>>> Thought we could support it transparently but seems there always have
> >>>>> border cases in advanced impl we sadly often rely on in prod ;).
> >>>>> It cant be a config access directly but we can add an update event
> for
> >>>> that
> >>>>> (if we dont want a cdi event we can allow sources to implement
> >> Updatable
> >>>> {
> >>>>> void afterUpdate(Collection keys) } probably which would do
> the
> >>>>> relationship without having a real cycle on the code)
> >>>>>
> >>>>>
> >>>>>
> >>>>> Romain Manni-Bucau
> >>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>>>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>>>> &l

Re: atomic access to config values

[Romain Manni-Bucau]

2018-04-06 8:51 GMT+02:00 Mark Struberg :

> Btw, ImmutableConfig would kind of suggest that it extends our Config
> interface, isn't?
>

Didn't think to that but it would be possible since we snapshot a subconfig
which can be a config. A snapshot sounds like it is the same object type
but "frozen" no?

Anyway what about making it an internal of ConfigImpl and not a Config
thing, then we don't care much of the name, right?


> But that's not the case, it is really something different.
>
> LieGrue,
> strub
>
>
> > Am 05.04.2018 um 22:02 schrieb Romain Manni-Bucau  >:
> >
> > Between the 3 createSnapshot or snapshot.
> >
> > What about ImmutableConfig and Config.toImmutable(keys)?
> >
> > Not a big deal though.
> >
> >
> > Le 5 avr. 2018 21:38, "Thomas Andraschko" 
> a
> > écrit :
> >
> > +1 for ConfigSnapshot and Config#snapshot
> >
> > 2018-04-05 21:32 GMT+02:00 Mark Struberg :
> >
> >> Had a long discussion with Tomas Langer about atomic access this
> > afternoon.
> >>
> >> What we came up with is probably better than 'ConfigTransaction',
> because
> >> the 'Transaction' term really creates the wrong impression.
> >>
> >> So what about
> >>
> >> * renaming ConfigTransaction to ConfigSnapshot and
> >> * Config#createTransation to
> >>- Config#resolveSnapshot or
> >>- Config#createSnapshot, or just
> >>- Config#snapshot ?
> >>
> >> Any thoughts? Or even any better ideas?
> >>
> >> txs and LieGrue,
> >> strub
> >>
> >>> Am 05.04.2018 um 10:39 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> Yes, you are right, in all cases the source must send an event to the
> >>> aggregator (config) to notify it to update its state (timestamp or
> not).
> >>> Thought we could support it transparently but seems there always have
> >>> border cases in advanced impl we sadly often rely on in prod ;).
> >>> It cant be a config access directly but we can add an update event for
> >> that
> >>> (if we dont want a cdi event we can allow sources to implement
> Updatable
> >> {
> >>> void afterUpdate(Collection keys) } probably which would do the
> >>> relationship without having a real cycle on the code)
> >>>
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >>> <https://rmannibucau.metawerx.net/> | Old Blog
> >>> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> >> rmannibucau> |
> >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >>> <https://www.packtpub.com/application-development/java-
> >> ee-8-high-performance>
> >>>
> >>> 2018-04-05 10:30 GMT+02:00 Mark Struberg :
> >>>
> >>>> But the writeLock would need to be performed by the ConfigSources.
> >>>> So we need to change them anyway.
> >>>>
> >>>> In the current solution any ConfigSource which performans an update
> >> would
> >>>> just need to call the reportAttributeChange callback.
> >>>>
> >>>> LieGrue,
> >>>> strub
> >>>>
> >>>>
> >>>>
> >>>>> Am 05.04.2018 um 09:39 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> >>>>> :
> >>>>>
> >>>>> 2018-04-05 9:31 GMT+02:00 Mark Struberg :
> >>>>>
> >>>>>> Romain, your mail client is pretty broken. All my original content
> > and
> >>>>>> your reply looks exactly the same.
> >>>>>> Please try to fix your reply-to rules ;)
> >>>>>>
> >>>>>>
> >>>>>>> This doesnt work for at least two reasons:
> >>>>>>>
> >>>>>>> 1. You assume you have request scoped
> >>>>>>
> >>>>>> Thus the fallback to native resolving in case there is no active
> >> Request
> >>>>>> Context. Means the current status quo.
> >>>>>>
> >>>>>
> >>>>>
> >>>>> RMB: not exactly since you need a workaround instead of no workaroun

Re: atomic access to config values

[Romain Manni-Bucau]

Between the 3 createSnapshot or snapshot.

What about ImmutableConfig and Config.toImmutable(keys)?

Not a big deal though.


Le 5 avr. 2018 21:38, "Thomas Andraschko"  a
écrit :

+1 for ConfigSnapshot and Config#snapshot

2018-04-05 21:32 GMT+02:00 Mark Struberg :

> Had a long discussion with Tomas Langer about atomic access this
afternoon.
>
> What we came up with is probably better than 'ConfigTransaction', because
> the 'Transaction' term really creates the wrong impression.
>
> So what about
>
> * renaming ConfigTransaction to ConfigSnapshot and
> * Config#createTransation to
> - Config#resolveSnapshot or
> - Config#createSnapshot, or just
> - Config#snapshot ?
>
> Any thoughts? Or even any better ideas?
>
> txs and LieGrue,
> strub
>
> > Am 05.04.2018 um 10:39 schrieb Romain Manni-Bucau  >:
> >
> > Yes, you are right, in all cases the source must send an event to the
> > aggregator (config) to notify it to update its state (timestamp or not).
> > Thought we could support it transparently but seems there always have
> > border cases in advanced impl we sadly often rely on in prod ;).
> > It cant be a config access directly but we can add an update event for
> that
> > (if we dont want a cdi event we can allow sources to implement Updatable
> {
> > void afterUpdate(Collection keys) } probably which would do the
> > relationship without having a real cycle on the code)
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <https://www.packtpub.com/application-development/java-
> ee-8-high-performance>
> >
> > 2018-04-05 10:30 GMT+02:00 Mark Struberg :
> >
> >> But the writeLock would need to be performed by the ConfigSources.
> >> So we need to change them anyway.
> >>
> >> In the current solution any ConfigSource which performans an update
> would
> >> just need to call the reportAttributeChange callback.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 05.04.2018 um 09:39 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> 2018-04-05 9:31 GMT+02:00 Mark Struberg :
> >>>
> >>>> Romain, your mail client is pretty broken. All my original content
and
> >>>> your reply looks exactly the same.
> >>>> Please try to fix your reply-to rules ;)
> >>>>
> >>>>
> >>>>> This doesnt work for at least two reasons:
> >>>>>
> >>>>> 1. You assume you have request scoped
> >>>>
> >>>> Thus the fallback to native resolving in case there is no active
> Request
> >>>> Context. Means the current status quo.
> >>>>
> >>>
> >>>
> >>> RMB: not exactly since you need a workaround instead of no workaround
> at
> >>> all so the code path would be better without that.
> >>>
> >>>
> >>>>
> >>>>> 2. You assume the tx has tx guarantee
> >>>>
> >>>> No, That's where I struggle. The name 'ConfigurationTransaction' is
> not
> >> a
> >>>> DB or JTA transaction! It's just that you have kind of an atomic
> access
> >>>> (like in ACID). Look at the code, it's done via optimistic locking.
> It's
> >>>> kind of a transactional isolation level READ-COMMITTED, but done on a
> >>>> programmatic level.
> >>>>
> >>>>>
> >>>>> The only way to have 2 is to lock the whole "current" config for the
> >> read
> >>>>> time (so a readwritelock for a simple impl) which makes this request
> >>>> scope
> >>>>> useless since you just need to swap the cache value and update it at
> >> once
> >>>>> with the lock.
> >>>>
> >>>> That would trash our performance. And it would require to start the
> lock
> >>>> at the beginning of a request, and then release it at the end of a
> >> request.
> >>>>
> >>>
> >>> No
> >>>
> >>>
> >>>> Mean

Re: atomic access to config values

[Romain Manni-Bucau]

Yes, you are right, in all cases the source must send an event to the
aggregator (config) to notify it to update its state (timestamp or not).
Thought we could support it transparently but seems there always have
border cases in advanced impl we sadly often rely on in prod ;).
It cant be a config access directly but we can add an update event for that
(if we dont want a cdi event we can allow sources to implement Updatable {
void afterUpdate(Collection keys) } probably which would do the
relationship without having a real cycle on the code)



Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-05 10:30 GMT+02:00 Mark Struberg :

> But the writeLock would need to be performed by the ConfigSources.
> So we need to change them anyway.
>
> In the current solution any ConfigSource which performans an update would
> just need to call the reportAttributeChange callback.
>
> LieGrue,
> strub
>
>
>
> > Am 05.04.2018 um 09:39 schrieb Romain Manni-Bucau  >:
> >
> > 2018-04-05 9:31 GMT+02:00 Mark Struberg :
> >
> >> Romain, your mail client is pretty broken. All my original content and
> >> your reply looks exactly the same.
> >> Please try to fix your reply-to rules ;)
> >>
> >>
> >>> This doesnt work for at least two reasons:
> >>>
> >>> 1. You assume you have request scoped
> >>
> >> Thus the fallback to native resolving in case there is no active Request
> >> Context. Means the current status quo.
> >>
> >
> >
> > RMB: not exactly since you need a workaround instead of no workaround at
> > all so the code path would be better without that.
> >
> >
> >>
> >>> 2. You assume the tx has tx guarantee
> >>
> >> No, That's where I struggle. The name 'ConfigurationTransaction' is not
> a
> >> DB or JTA transaction! It's just that you have kind of an atomic access
> >> (like in ACID). Look at the code, it's done via optimistic locking. It's
> >> kind of a transactional isolation level READ-COMMITTED, but done on a
> >> programmatic level.
> >>
> >>>
> >>> The only way to have 2 is to lock the whole "current" config for the
> read
> >>> time (so a readwritelock for a simple impl) which makes this request
> >> scope
> >>> useless since you just need to swap the cache value and update it at
> once
> >>> with the lock.
> >>
> >> That would trash our performance. And it would require to start the lock
> >> at the beginning of a request, and then release it at the end of a
> request.
> >>
> >
> > No
> >
> >
> >> Means if you would want to update some value (write-lock) then you would
> >> need to wait until all requests are finished (might take some seconds),
> >> BLOCK all new incoming requests (stand-still in the whole app) and only
> >> then you could do the update :(
> >>
> >
> >
> > We would have:
> >
> > withWriteLock(updateConfig())
> >
> > and
> >
> > withReadLock(updateConfigInstanceCache())
> >
> > It means the overhead is null everytime except until there is a write in
> > the config which is the only way to guarantee the atomicity of the
> updates
> > (switch to another ftp/http/... server typically).
> >
> > You can think to a lock per key*s* but it doesnt work cause we support
> > placeholding and this means you must lock the whole config to impl it.
> >
> > This impl is good in terms of perf since the updates will not be that
> > frequent. If you care of that small "stop the world' - but keep it mind
> it
> > should be very small - then we can use a queue to update the data so the
> > write fills a queue (or just a flag) which once in the right state will
> > force the consumers (config instances) to reevaluate the current values.
> > The issue here is that you still need to lock the world to copy the
> config
> > state (you cant assume it is scannable in most of the cases) to stay
> atomic.
> >
> > Long story short: there is no real choice if you want to be atomic
> > transparently (ie without adding a relationship between keys + keep in
> the
> > instance this relationship to know what

Re: atomic access to config values

[Romain Manni-Bucau]

2018-04-05 9:31 GMT+02:00 Mark Struberg :

> Romain, your mail client is pretty broken. All my original content and
> your reply looks exactly the same.
> Please try to fix your reply-to rules ;)
>
>
> > This doesnt work for at least two reasons:
> >
> > 1. You assume you have request scoped
>
> Thus the fallback to native resolving in case there is no active Request
> Context. Means the current status quo.
>


RMB: not exactly since you need a workaround instead of no workaround at
all so the code path would be better without that.


>
> > 2. You assume the tx has tx guarantee
>
> No, That's where I struggle. The name 'ConfigurationTransaction' is not a
> DB or JTA transaction! It's just that you have kind of an atomic access
> (like in ACID). Look at the code, it's done via optimistic locking. It's
> kind of a transactional isolation level READ-COMMITTED, but done on a
> programmatic level.
>
> >
> > The only way to have 2 is to lock the whole "current" config for the read
> > time (so a readwritelock for a simple impl) which makes this request
> scope
> > useless since you just need to swap the cache value and update it at once
> > with the lock.
>
> That would trash our performance. And it would require to start the lock
> at the beginning of a request, and then release it at the end of a request.
>

No


> Means if you would want to update some value (write-lock) then you would
> need to wait until all requests are finished (might take some seconds),
> BLOCK all new incoming requests (stand-still in the whole app) and only
> then you could do the update :(
>


We would have:

withWriteLock(updateConfig())

and

withReadLock(updateConfigInstanceCache())

It means the overhead is null everytime except until there is a write in
the config which is the only way to guarantee the atomicity of the updates
(switch to another ftp/http/... server typically).

You can think to a lock per key*s* but it doesnt work cause we support
placeholding and this means you must lock the whole config to impl it.

This impl is good in terms of perf since the updates will not be that
frequent. If you care of that small "stop the world' - but keep it mind it
should be very small - then we can use a queue to update the data so the
write fills a queue (or just a flag) which once in the right state will
force the consumers (config instances) to reevaluate the current values.
The issue here is that you still need to lock the world to copy the config
state (you cant assume it is scannable in most of the cases) to stay atomic.

Long story short: there is no real choice if you want to be atomic
transparently (ie without adding a relationship between keys + keep in the
instance this relationship to know what to update when there is a write
which goes to the placeholding replacements).
To already have use RW for that I don't see it as a perf blocker.

What about trying and measure it?





>
>
> LieGrue,
> strub
>
>
>
>
> > Am 04.04.2018 um 23:55 schrieb Romain Manni-Bucau  >:
> >
> > Le 4 avr. 2018 19:37, "Mark Struberg"  a
> écrit :
> >
> > But that's still problematic.
> > you have request1 ongoing and call in the following order:
> > ftpConfig.host();ftpConfig.port();// <- and here some config update
> happens
> > ftpConfig.username();
> >
> >
> > So even if we update the whole ftpConfig 'at once' you will end up with
> > mixed up information in this request, right?
> > The only viable solution is to have a @RequestScoped ConfigTransaction
> > spanning all those TypedResolvers of the whole @Configuration. At least I
> > could not find any better solution.
> >
> >
> > This doesnt work for at least two reasons:
> >
> > 1. You assume you have request scoped
> > 2. You assume the tx has tx guarantee
> >
> > The only way to have 2 is to lock the whole "current" config for the read
> > time (so a readwritelock for a simple impl) which makes this request
> scope
> > useless since you just need to swap the cache value and update it at once
> > with the lock.
> >
> > LieGrue,strub
> >
> >
> >
> >On Wednesday, 4 April 2018, 18:44:13 CEST, Romain Manni-Bucau <
> > rmannibu...@gmail.com> wrote:
> >
> > Since the cache is per instance we should just clear it on eviction at
> once
> > IMHO
> > the issue is: do you want to populate it at once too? tempted to say yes
> >
> > this means it can always be active but requires to be able to copy the
> > current config state or prevent *any* update while populating such
> "cache"

Re: atomic access to config values

[Romain Manni-Bucau]

Le 4 avr. 2018 19:37, "Mark Struberg"  a écrit :

But that's still problematic.
you have request1 ongoing and call in the following order:
ftpConfig.host();ftpConfig.port();// <- and here some config update happens
ftpConfig.username();


So even if we update the whole ftpConfig 'at once' you will end up with
mixed up information in this request, right?
The only viable solution is to have a @RequestScoped ConfigTransaction
spanning all those TypedResolvers of the whole @Configuration. At least I
could not find any better solution.


This doesnt work for at least two reasons:

1. You assume you have request scoped
2. You assume the tx has tx guarantee

The only way to have 2 is to lock the whole "current" config for the read
time (so a readwritelock for a simple impl) which makes this request scope
useless since you just need to swap the cache value and update it at once
with the lock.

LieGrue,strub



On Wednesday, 4 April 2018, 18:44:13 CEST, Romain Manni-Bucau <
rmannibu...@gmail.com> wrote:

 Since the cache is per instance we should just clear it on eviction at once
IMHO
the issue is: do you want to populate it at once too? tempted to say yes

this means it can always be active but requires to be able to copy the
current config state or prevent *any* update while populating such "cache"

+1 to do it without any flag


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
|
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance
>

2018-04-04 18:40 GMT+02:00 Mark Struberg :

> We should also enhance the support to include @Configuration.
> e.g. if you have some class like
> @Configuration(cacheFor=60, cacheUnit=TimeUnit.MINUTES)
> public class FtpConfigation {  String host();  Integer port();  String
> username();  String encryptedPwd();}
>
> Then you will likely resolve all those values in an atomic way. This means
> that the values are basically backed by a @RequestScoped ConfigTransaction
> holder.
> Do we _always_ like to activate this feature?Or do we like to introduce
> another flag in the @Configuration annotation?
> What about threads which have no request Context active?Should it
> automatically fallback to on-demand resolving?
> LieGrue,strub
>
>On Wednesday, 4 April 2018, 18:08:09 CEST, Mark Struberg
>  wrote:
>
>  hi folks!
> please review the proposed solution for DELTASPIKE-1335
> https://issues.apache.org/jira/browse/DELTASPIKE-1335
>
> Not quite sure about startTransaction and ConfigTransation are the right
> terms. Happy to get feedback!
>
> txs and LieGrue,strub
>

Re: atomic access to config values

[Romain Manni-Bucau]

Since the cache is per instance we should just clear it on eviction at once
IMHO
the issue is: do you want to populate it at once too? tempted to say yes

this means it can always be active but requires to be able to copy the
current config state or prevent *any* update while populating such "cache"

+1 to do it without any flag


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-04-04 18:40 GMT+02:00 Mark Struberg :

> We should also enhance the support to include @Configuration.
> e.g. if you have some class like
> @Configuration(cacheFor=60, cacheUnit=TimeUnit.MINUTES)
> public class FtpConfigation {  String host();  Integer port();  String
> username();  String encryptedPwd();}
>
> Then you will likely resolve all those values in an atomic way. This means
> that the values are basically backed by a @RequestScoped ConfigTransaction
> holder.
> Do we _always_ like to activate this feature?Or do we like to introduce
> another flag in the @Configuration annotation?
> What about threads which have no request Context active?Should it
> automatically fallback to on-demand resolving?
> LieGrue,strub
>
> On Wednesday, 4 April 2018, 18:08:09 CEST, Mark Struberg
>  wrote:
>
>  hi folks!
> please review the proposed solution for DELTASPIKE-1335
> https://issues.apache.org/jira/browse/DELTASPIKE-1335
>
> Not quite sure about startTransaction and ConfigTransation are the right
> terms. Happy to get feedback!
>
> txs and LieGrue,strub
>

Re: [DISCUSS] ds for cdi 1.2+ only

[Romain Manni-Bucau]

All work for me and the apps i work on since a few years.

Le 3 avr. 2018 22:17, "Thomas Andraschko"  a
écrit :

> +1 for 3)
> the workarounds are really not that big...
>
> i would leave it as it is for now and start with DS 2.0 (= CDI2.0 only) the
> next months.
>
> 2018-04-03 22:06 GMT+02:00 Gerhard Petracek :
>
> > hi @ all,
> >
> > since we will need to maintain v1.8.x for a while and it's too early for
> > using cdi 2.0 (for a while), we should discuss if we should have one
> branch
> > using cdi 1.2+.
> > it would allow to get rid of several workarounds (and the corresponding
> > warnings during the bootstrapping process).
> >
> > we had a short discussion in the irc-channel about the following options:
> > #1) ds v1.x as it is right now; ds v2: jdk8 with cdi 1.2+
> >
> > vs
> >
> > #2) ds v1.8.x: as it is right now; ds > v1.8.x && < v2.x: jdk8 with cdi
> > v1.2+; ds v2: jdk8 with cdi 2.0+
> >
> > vs
> >
> > #3) we don't care about v1.2 as a min. requirement at all
> > (the workarounds are minimal anyway and users can continue to ignore the
> > warnings during the bootstrapping process)
> >
> > or for sure
> > #4) [any other nice suggestion]
> >
> > -> please send your preferred approach
> >
> > regards,
> > gerhard
> >
>

[jira] [Commented] (DELTASPIKE-1333) Support default methods in interface based configuration

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415151#comment-16415151
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1333:


Hi Niels,

Do you want to do a PR on github to fix it? Technically we'd want to add a 
small SPI (ServiceLoader probably) in ConfigurationExtension to load a 
ConfigurationProxyProvider which instantiate a proxy from its Class. It would 
be used in ProxyConfigurationLifecycle#create. By default we would keep current 
implementation without default support using java proxy but if partialbean 
module is present we would use the partialbean bytecode generation which can 
support default methods.

Side note: no need of default methods for this use case, use a converter ;).

Romain

> Support default methods in interface based configuration
> 
>
> Key: DELTASPIKE-1333
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1333
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Configuration
>Affects Versions: 1.8.1
> Environment: Java 8, DeltaSpike 1.8.1
>Reporter: Niels Ull Harremoes
>Priority: Minor
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> I wanted to implement a default method in one of my configuration methods as 
> a simple way to configure a Duration:
> {code:java}
> @Configuration
> interface CacheConfig {
>   @ConfigProperty(name = "cache.lifetime", defaultValue = "P1D")
>   String cacheLifetime();
>   default Duration getCacheLifetimeDuration() {
>     try {
>        return Duration.parse(cacheLifetime());
>     } catch (DateTimeParseException e) {
>         ...
>   }
> }
> {code}
> However, a runtime I get the error
> {quote}java.lang.UnsupportedOperationException: public default 
> java.time.Duration com.example.CacheConfig.getLifetimeDuration() doesn't have 
> @ConfigProperty and therefore is illegal
> {quote}
> It would be nice if default methods were not processed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] require Java8 and move to Deltaspike-1.9.x version?

[Romain Manni-Bucau]

2018-03-01 15:50 GMT+01:00 John D. Ament :

> IMHO to move to Java 8 we need to drop support for EE6/EE7.  So to me that
> says the next version is 2.0 not 1.9.x.
>

It is way too early for cdi 2, almost no users rely on that yet compared to
cdi 1.x.


>
> There are some weld 1.1 versions that support this, but no testable AS7
> instance that we can check against.
>

Isnt wildfly enough now? Maybe JBoss guys can help us here as well.


>
> John
>
> On Thu, Mar 1, 2018 at 9:35 AM Cody Lerum  wrote:
>
> > +1 there is no reason for someone running Java 7 to expect new features
> > from Deltaspike.
> >
> > On Feb 28, 2018 9:48 PM, "Mark Struberg" 
> > wrote:
> >
> > > Hi folks!
> > >
> > > Our build, etc in theory still runs with Java6.
> > > As typical with ASF projects we make battle prooven projects for
> > > production.
> > > That means we take backward compatibility really serious.
> > >
> > > But I think it's finally time to up the game to Java8.
> > > To indicate this I suggest to move from currently 1.8.x to 1.9.x.
> > >
> > > Note that all the rest will still be backward compatible with older
> > > versions!
> > > We also might still ship 1.8.2, 1.8.3, etc as Java7 compatible version
> if
> > > there is any necessity.
> > >
> > > Any objections?
> > >
> > > LieGrue,
> > > strub
> >
>

Re: [DISCUSS] require Java8 and move to Deltaspike-1.9.x version?

[Romain Manni-Bucau]

+1, even big data libs like apache beam are java 8 based now so if big data
moved to j8, server techno should have moved already IMHO ;)

Le 1 mars 2018 05:48, "Mark Struberg"  a écrit :

> Hi folks!
>
> Our build, etc in theory still runs with Java6.
> As typical with ASF projects we make battle prooven projects for
> production.
> That means we take backward compatibility really serious.
>
> But I think it's finally time to up the game to Java8.
> To indicate this I suggest to move from currently 1.8.x to 1.9.x.
>
> Note that all the rest will still be backward compatible with older
> versions!
> We also might still ship 1.8.2, 1.8.3, etc as Java7 compatible version if
> there is any necessity.
>
> Any objections?
>
> LieGrue,
> strub

Re: bringing interdyn and invomon to DeltaSpike?

[Romain Manni-Bucau]

Hi Mark

I like interdync and it is a generic fit but invomon is a bit limited in
current flavor and I would be tempted to say we can just inherit from the
related sirona part of code if we want to go this way.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>

2018-02-09 10:49 GMT+01:00 Mark Struberg :

> Hi folks!
>
> Some of you might know my interdyn + invomon projects [1].
>
> For the others, what are they about?
>
> interdyn is a dynamic interceptor binding Extension.
> It allows to declare a regexp pattern and a class name of an Interceptor
> annotation.
> It then applies this annotation to all the classes which map the regexp.
> Of course you can define multiple rules.
>
> rule.1.match=.*ServiceImpl
> rule.1.interceptor=net.struberg.devtools.cdi.invomon.InvocationMonitored
>
> The other part is exactly that @InvocationMonitored interceptor.
>
> It logs the most expensive methods and classes after each request.
> The output looks like the following:
>
> 2011-03-19 12:36:27,291 [2046767960@qtp-1243908618-9]  INFO
> invomon.InvocationResultLogger Top Class Invocations:
>   count: 51 net.struberg.myproject.core.be.semester.
> SemesterRemoteServiceImpl
>   count: 21 net.struberg.myproject.core.be.security.service.
> SecurityServiceImpl
>   count: 5  net.struberg.myproject.util.be.config.ConfigServiceImpl
>   count: 2  net.struberg.myproject.course.be.CourseServiceImpl
>   count: 1  net.struberg.myproject.events.be.EventServiceImpl
>   count: 1  net.struberg.myproject.core.be.persons.
> PersonRemoteServiceImpl
>   count: 1  net.struberg.myproject.course.be.LecturerServiceImpl
>   count: 1  net.struberg.myproject.events.be.EventRemoteServiceImpl
>
> 2011-03-19 12:36:27,292 [2046767960@qtp-1243908618-9]  INFO
> invomon.InvocationResultLogger Top Method Invocations:
>   dur[ms]: 442.48096count: 1net.struberg.myproject.course.
> be.CourseServiceImpl#deleteCourse
>   dur[ms]: 349.34717count: 1net.struberg.myproject.course.
> be.CourseServiceImpl#getByFilter
>   dur[ms]: 104.53423count: 1net.struberg.myproject.events.
> be.EventRemoteServiceImpl#getEvent
>   dur[ms]: 100.43162count: 1net.struberg.myproject.events.
> be.EventServiceImpl#getEvent
>   dur[ms]: 24.677048count: 1net.struberg.myproject.course.
> be.LecturerServiceImpl#getEmployeeIdsInvolvedInOrgUnitCourses
>   dur[ms]: 1.596834 count: 1net.struberg.myproject.core.
> be.persons.PersonRemoteServiceImpl#getByEmployeeIdList
>   dur[ms]: 0.892522 count: 51   net.struberg.myproject.core.
> be.semester.SemesterRemoteServiceImpl#getCorrespondingSemesterCode
>   dur[ms]: 0.288455 count: 5net.struberg.myproject.util.
> be.config.ConfigServiceImpl#getStringProperty
>   dur[ms]: 0.248038 count: 3net.struberg.myproject.core.
> be.security.service.SecurityServiceImpl#isGranted
>   dur[ms]: 0.203102 count: 18   net.struberg.myproject.core.
> be.security.service.SecurityServiceImpl#isAuthenticated
>
>
> The initial version requires an own property file. But of course all this
> configuration could also be provided via DS-config.
>
> wdyt?
> Worth moving over to DeltaSpike?
>
> LieGrue,
> strub
>
>
>
> [1] https://github.com/struberg/interdyn
>
>

Re: Wrong license on proxy-module impl-asm

[Romain Manni-Bucau]

+1 to fix the license and keep the shade


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>

2018-01-15 9:59 GMT+01:00 Thomas Andraschko :

> We shaded it for compatibility reasons as many libs use ASM.
>
> 2018-01-15 9:06 GMT+01:00 Mark Struberg :
>
> > +1 can you plz file a ticket?
> >
> > txs and LieGrue,
> > strub
> >
> >
> > > Am 13.01.2018 um 15:35 schrieb John D. Ament :
> > >
> > > The license for proxy-module's impl-asm binary JAR is generated
> > > incorrectly.  Do we need to include a shaded ASM?  If we do, we need to
> > > include the BSD-3-Clause license in the generated JAR.
> > >
> > > John
> >
> >
>

Re: provide a default Scheduler which is not using quartz as default?

[Romain Manni-Bucau]

@Mark: here cause tomee already has ee concurrency utilities which could be
used to impl @Schedule(persistent=false) - just no will/need yet.

Le 5 janv. 2018 20:10, "John D. Ament"  a écrit :

> On Fri, Jan 5, 2018 at 2:00 PM John D. Ament 
> wrote:
>
> > On Fri, Jan 5, 2018 at 1:21 PM Mark Struberg 
> > wrote:
> >
> >> > Shouldnąt we just disable the update check in our quartz
> configuration?
> >>
> >> Well there is a flag to disable this behaviour, but a.) it's hard to set
> >> (requires -D) and it doesn't disable 100%.
> >> The code still does some http calls out :/
> >>
> >
> > You can disable it programmatically.  I've done wireshark checks, there
> is
> > no other HTTP calls made out.  Here's a quick patch that does it:
> >
> >
> > https://github.com/johnament/deltaspike/commit/
> 5a4fec98ff3f8f6ed6b54c36332bb8621cd3b09d
> >
>
> Here's a more interesting thing, looks like for Quartz 2.3 they changed
> from an opt out to an opt in -
> https://github.com/quartz-scheduler/quartz/commit/
> dfe1e5a3cc248e2a46a6ea55567aaa6dc8e15ca5
>
> John
>
>
> >
> >
> > John
> >
> >
> >>
> >> That's really bad, and the terracotta community (or rather the firm
> >> behind it) declined to disable it by default since 2010 :/
> >>
> >> @Tomas, yes there is additional effort to maintain it. But imo it's
> worth
> >> it.
> >>
> >> @Romain, John the question for me is rather where we do like to keep the
> >> code.
> >> Either here in DeltaSpike or at geronimo? The reason is that we might
> >> also later use this in other projects (TomEE) as well.
> >>
> >> For now I'd just start to play a bit with it over here and then we can
> >> still move it around later.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> > Am 05.01.2018 um 17:44 schrieb Arne Limburg <
> >> arne.limb...@openknowledge.de>:
> >> >
> >> > Hi Mark,
> >> >
> >> > Shouldnąt we just disable the update check in our quartz
> configuration?
> >> >
> >> > Cheers,
> >> > Arne
> >> >
> >> >
> >> > Am 05.01.18 17:39 schrieb "Mark Struberg" unter
> >> > :
> >> >
> >> >> Hi folks!
> >> >> Since I've now had a few complaints about Quartz 'phoning home'
> >> (totally
> >> >> useless update check), I'm really inclined to just kick out quartz
> and
> >> >> implement the Scheduler ourselves.
> >> >> Implementing a proper Scheduler is not that complicated anyway, so do
> >> we
> >> >> like to roll this ourselves?
> >> >> Or do you think I underestimate the effort?
> >> >>
> >> >> LieGrue,strub
> >> >
> >>
> >>
>

Re: provide a default Scheduler which is not using quartz as default?

[Romain Manni-Bucau]

+100


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau>

2018-01-05 17:39 GMT+01:00 Mark Struberg :

> Hi folks!
> Since I've now had a few complaints about Quartz 'phoning home' (totally
> useless update check), I'm really inclined to just kick out quartz and
> implement the Scheduler ourselves.
> Implementing a proper Scheduler is not that complicated anyway, so do we
> like to roll this ourselves?
> Or do you think I underestimate the effort?
>
> LieGrue,strub
>

[jira] [Commented] (DELTASPIKE-1311) Allow Excluded Repositories

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16313201#comment-16313201
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1311:


No need of veto since it will not be seen so I tend to join Gerhard here, is it 
only a legacy, EE 6 enhancement? If so we should fully support exclude (doable 
since part of the core  feature) IMHO.

> Allow Excluded Repositories
> ---
>
> Key: DELTASPIKE-1311
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1311
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Affects Versions: 1.8.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.8.2
>
>
> When a repository is discovered, if it has @Exclude on it, then don't include 
> it as a possible repository bean.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] release Apache DeltaSpike-1.8.1

[Romain Manni-Bucau]

+1

Le 30 déc. 2017 21:14, "Gerhard Petracek"  a écrit :

> +1
>
> regards,
> gerhard
>
>
>
> 2017-12-30 17:39 GMT+01:00 Mark Struberg :
>
> > Hi folks!
> >
> > I did run the necessary steps for releasing DeltaSpike-1.8.1
> >
> > The following bugs and improvements got implemented:
> >
> > Bug
> >
> > • [DELTASPIKE-1252] - data-documentation missing Optional return
> > value
> > • [DELTASPIKE-1271] - [perf] cache Transactional
> > • [DELTASPIKE-1272] - ConfigResolver asList breaks if no value is
> > found
> > • [DELTASPIKE-1275] - Build fails on Linux because Testclass
> > filenames are to long
> > • [DELTASPIKE-1278] - PropertyFileConfig does not respect
> optional
> > on external resources
> > • [DELTASPIKE-1281] - Deltaspike does not pass BeanManager to
> > persistenf factory config using "javax.persistence.bean.manager"
> > • [DELTASPIKE-1287] - asList() getValue() fails with a NPE if no
> > configured value exists
> > • [DELTASPIKE-1288] - Default values are not interpolated
> > • [DELTASPIKE-1294] - Secured Stereotypes are not applied to
> > inherited methods
> > • [DELTASPIKE-1296] - PropertyFileConfig doesn't work with
> > internal extensions
> > • [DELTASPIKE-1302] - ThreadPoolManager: ExecutorService map is
> > always empty
> > • [DELTASPIKE-1303] - @Configuration proxies should support List
> > without converters
> > • [DELTASPIKE-1305] - Multiple ds:windowId leads to multiple
> > redirects
> > • [DELTASPIKE-1306] - IE sometimes doesn't set window.name
> > correctly
> > • [DELTASPIKE-1307] - Deltaspike JSF: XSS
> WindowIdHtmlRenderer.java
> > Improvement
> >
> > • [DELTASPIKE-940] - @Transactional and @EntityManagerConfig each
> > use a different method to resolve EntityManagers
> > • [DELTASPIKE-1070] - Refactor RepositoryComponent/s
> > • [DELTASPIKE-1258] - skip flush with one EntityManager
> > • [DELTASPIKE-1267] - Remove second factory mechanism of
> > QueryBuilder's
> > • [DELTASPIKE-1268] - QueryProcessorFactory should be a bean
> > • [DELTASPIKE-1269] - [perf] Cache singleResultType per method
> > • [DELTASPIKE-1270] - [perf] cache requiresTransaction per method
> > • [DELTASPIKE-1274] - Refactor proxy-module / improve performance
> > • [DELTASPIKE-1279] - SimpleSecurityViolation needs
> equals/hashcode
> > • [DELTASPIKE-1283] - Placeholders not supported for defaults
> > • [DELTASPIKE-1289] - GlobalInterceptorExtension could reuse
> > BeanManager
> > • [DELTASPIKE-1293] - CDI qualifiers support for JSF converters
> > • [DELTASPIKE-1304] - Make CdiTestRunner use "flat" deployment on
> > Weld by default
> > Task
> >
> > • [DELTASPIKE-1259] - upgraded version numbers
> > • [DELTASPIKE-1297] - add test with a customized
> DynamicMockManager
> > • [DELTASPIKE-1298] - document customization of a
> > DynamicMockManager
> > Test
> >
> > • [DELTASPIKE-1273] - Test against OWB 2
> >
> >
> >
> > The staging repo is
> > https://repository.apache.org/content/repositories/
> > orgapachedeltaspike-1046/
> >
> > The source release can be found at
> > https://repository.apache.org/content/repositories/
> > orgapachedeltaspike-1046/org/apache/deltaspike/deltaspike/1.8.1/
> > sha1 is 4d7db712629261a92e6dcddfdcb7a446015bf432
> >
> >
> > Please VOTE:
> >
> > [+1] yea, let's ship it
> > [+0] meh, don't care
> > [-1] yikes, stop because ${showstopper}
> >
> > The VOTE is open for 72h.
> >
> >
> > Here is my own +1
> >
> > txs and LieGrue,
> > strub
>

Re: CI for DeltaSpike?

[Romain Manni-Bucau]

Sorry Matej, I don't get how Travis would help since you can do the
same with jenkins which is already configured.

Having the default build running on both weld and OWB would be more
beneficial IMHO, but it is just the opinion from my side of the fence
and experience.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-30 14:57 GMT+01:00 Matej Novotny :
> Thanks, but it was more of a rhetorical question (you saved me some digging 
> though).
> Still my claim holds true, nobody cares about them much. They must have been 
> failing for quite some time now
> Not to mention they aren't even updated to latest Weld version (or WildFly 
> version for that matter).
>
>
> Matej
>
> ----- Original Message -
>> From: "Romain Manni-Bucau" 
>> To: dev@deltaspike.apache.org
>> Sent: Wednesday, November 29, 2017 5:03:02 PM
>> Subject: Re: CI for DeltaSpike?
>>
>> Hi Matej,
>>
>> they are all on the ASF jenkins:
>> https://builds.apache.org/view/A-D/view/DeltaSpike/
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>>
>>
>> 2017-11-29 16:47 GMT+01:00 Matej Novotny :
>> > Hello
>> >
>> > I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant
>> > Integration OFC) and DeltaSpike.
>> > Apparently, there is no such thing now and even while some CI jobs exist
>> > (where are they, anyway?), nobody really pays attention to them.
>> > I mean those for Weld ones must have been failing for few months and yet
>> > the JIRAs causing that were happily marked as Resolved.
>> > Meaning whoever fixed that probably only ran smoke tests with OWB.
>> >
>> > Today I noticed there is going to be a release soon and so I quikly went to
>> > check how the build/tests fare with Weld profiles.
>> > Turned out to be a disaster. So I then have to spend considerable time
>> > backtracking the changes and figuring out the actual problem.
>> > And it's not the first time this happened either.
>> >
>> > Therefore I wanted to bring up the topic of CI to avoid this in the future.
>> > The ideal scenario is sending PRs and having them checked *before* merging
>> > - obviously not an option here.
>> > The GH repo is but a mirror (something we have to stick to I presume) which
>> > makes it more complex, but still, it should be possible to set up a Travis
>> > build on GH master which will execute after every sync.
>> > That way the failures would be readily visible (via the travis status
>> > "button").
>> > In order to discover most problems there is no need for a complete test
>> > matrix, it would do to just have two version of OWB and Weld without EE
>> > container (with just the Arq. one).
>> >
>> >
>> > A penny for your thoughts?
>> >
>> >
>> > Regards
>> > Matej
>>

Re: CI for DeltaSpike?

[Romain Manni-Bucau]

Hi Matej,

they are all on the ASF jenkins:
https://builds.apache.org/view/A-D/view/DeltaSpike/

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-29 16:47 GMT+01:00 Matej Novotny :
> Hello
>
> I wanted to bring up a topic of CI (Continuous Irritation - eh, I meant 
> Integration OFC) and DeltaSpike.
> Apparently, there is no such thing now and even while some CI jobs exist 
> (where are they, anyway?), nobody really pays attention to them.
> I mean those for Weld ones must have been failing for few months and yet the 
> JIRAs causing that were happily marked as Resolved.
> Meaning whoever fixed that probably only ran smoke tests with OWB.
>
> Today I noticed there is going to be a release soon and so I quikly went to 
> check how the build/tests fare with Weld profiles.
> Turned out to be a disaster. So I then have to spend considerable time 
> backtracking the changes and figuring out the actual problem.
> And it's not the first time this happened either.
>
> Therefore I wanted to bring up the topic of CI to avoid this in the future. 
> The ideal scenario is sending PRs and having them checked *before* merging - 
> obviously not an option here.
> The GH repo is but a mirror (something we have to stick to I presume) which 
> makes it more complex, but still, it should be possible to set up a Travis 
> build on GH master which will execute after every sync.
> That way the failures would be readily visible (via the travis status 
> "button").
> In order to discover most problems there is no need for a complete test 
> matrix, it would do to just have two version of OWB and Weld without EE 
> container (with just the Arq. one).
>
>
> A penny for your thoughts?
>
>
> Regards
> Matej

[jira] [Resolved] (DELTASPIKE-1303) @Configuration proxies should support List without converters

[Romain Manni-Bucau (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Manni-Bucau resolved DELTASPIKE-1303.

Resolution: Fixed

> @Configuration proxies should support List without converters
> -
>
> Key: DELTASPIKE-1303
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1303
> Project: DeltaSpike
>  Issue Type: Bug
>    Reporter: Romain Manni-Bucau
>    Assignee: Romain Manni-Bucau
> Fix For: 1.8.1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (DELTASPIKE-1303) @Configuration proxies should support List without converters

[Romain Manni-Bucau (JIRA)]

Romain Manni-Bucau created DELTASPIKE-1303:
--

 Summary: @Configuration proxies should support List without 
converters
 Key: DELTASPIKE-1303
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1303
 Project: DeltaSpike
  Issue Type: Bug
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.8.1






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] releasing 1.8.1?

[Romain Manni-Bucau]

+1 the config lifecycle enhancement will be great to cite only it

Le 29 nov. 2017 08:48, "Mark Struberg"  a écrit :

> hi folks!
>
> I'd like to release 1.8.1 in my spare cycles over the next days.
> Any objections?
>
> Would be way cool if people could glimpse through their tickets and
> update/resolve them accordingly.
>
> txs and LieGrue,
> strub
>
>

Re: propertyfileconfig and lifecycle

[Romain Manni-Bucau]

works for me, thks Mark

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn


2017-11-27 15:51 GMT+01:00 Mark Struberg :
> We can move it from AfterDeploymentValidation to AfterBeanDiscovery.
> My argument was about why we _not_ do it immediately in ProcessAnnotatedType.
>
> Will go ahead.
>
> LieGrue,
> strub
>
>> Am 27.11.2017 um 14:32 schrieb Romain Manni-Bucau :
>>
>> Hi guys,
>>
>> I would like to discuss DELTASPIKE-1296 (and avoid jira noise ;))
>>
>> Issue is AfterDeploymentValidation order of extensions is not
>> deterministic and therefore we can end up in cases where our
>> extensions are not usable in between them cause of that. it is
>> typically the case for the config extension which is used by all other
>> ones.
>>
>> To solve it - keeping the deterministic behavior we have - we can:
>>
>> 1. register earlier the PropertyFileConfig (AfterBeanDiscovery?)
>> 2. have a single AfterDeploymentValidation observer in all our
>> codebase and be able to sort extensions here (@Priority or a custom
>> @Order). Note we can apply it to [Before|After]BeanDiscovery too.
>> 3. surely others
>>
>> Goal is to ensure the mainstream programming model we have works in
>> most cases and there is no arbitrary reason to not have it working.
>>
>> wdyt? Personally I'm tempted to say 2. is not a bad compromise and
>> would bring a lot of value by itself even if not 100% aligned on CDI
>> programming model.
>>
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>

propertyfileconfig and lifecycle

[Romain Manni-Bucau]

Hi guys,

I would like to discuss DELTASPIKE-1296 (and avoid jira noise ;))

Issue is AfterDeploymentValidation order of extensions is not
deterministic and therefore we can end up in cases where our
extensions are not usable in between them cause of that. it is
typically the case for the config extension which is used by all other
ones.

To solve it - keeping the deterministic behavior we have - we can:

1. register earlier the PropertyFileConfig (AfterBeanDiscovery?)
2. have a single AfterDeploymentValidation observer in all our
codebase and be able to sort extensions here (@Priority or a custom
@Order). Note we can apply it to [Before|After]BeanDiscovery too.
3. surely others

Goal is to ensure the mainstream programming model we have works in
most cases and there is no arbitrary reason to not have it working.

wdyt? Personally I'm tempted to say 2. is not a bad compromise and
would bring a lot of value by itself even if not 100% aligned on CDI
programming model.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn

[jira] [Commented] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266801#comment-16266801
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1296:


If we register them at AfterBeanDiscovery phase we would be deterministic and 
solve the inter extension issue.

Strictly speaking having a single AfterDeploymentValidation deltaspike 
extension and sorting ourself all the extensions using this hook would make it 
deterministic too and solve the original issue.

In any case current implementation is not usable since it leads to a 
misbehavior in most cases cause using the SPI file for a PropertyFileConfig is 
all but recommanded in all our doc and would lead to a simple ConfigSource so 
is not justified.

> PropertyFileConfig doesn't work with internal extensions
> 
>
> Key: DELTASPIKE-1296
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.8.0
>Reporter: Romain Manni-Bucau
>Assignee: Mark Struberg
>
> We register PropertyFileConfig in AfterDeploymentValidation hook but 
> extensions potentially already read the config entries. Technically there is 
> probably no blocker to do it earlier and we should probably ensure all our 
> extensions read keys in AfterDeploymentValidation.
> My use case was a configured cron expression in the scheduler usage.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions

[Romain Manni-Bucau (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Manni-Bucau reopened DELTASPIKE-1296:


> PropertyFileConfig doesn't work with internal extensions
> 
>
> Key: DELTASPIKE-1296
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.8.0
>    Reporter: Romain Manni-Bucau
>Assignee: Mark Struberg
>
> We register PropertyFileConfig in AfterDeploymentValidation hook but 
> extensions potentially already read the config entries. Technically there is 
> probably no blocker to do it earlier and we should probably ensure all our 
> extensions read keys in AfterDeploymentValidation.
> My use case was a configured cron expression in the scheduler usage.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266630#comment-16266630
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1296:


Hi Mark,

issue is really to have a config module not compatible with other module usage.

1 should directly register the config and not way for any later phase to ensure 
it is used by other extensions IMO.

I'm also fine forbidding any discovery other than SPI one since it would make 
it work smoothly but it is less user friendly.

> PropertyFileConfig doesn't work with internal extensions
> 
>
> Key: DELTASPIKE-1296
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.8.0
>Reporter: Romain Manni-Bucau
>Assignee: Mark Struberg
>
> We register PropertyFileConfig in AfterDeploymentValidation hook but 
> extensions potentially already read the config entries. Technically there is 
> probably no blocker to do it earlier and we should probably ensure all our 
> extensions read keys in AfterDeploymentValidation.
> My use case was a configured cron expression in the scheduler usage.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (DELTASPIKE-1296) PropertyFileConfig doesn't work with internal extensions

[Romain Manni-Bucau (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Romain Manni-Bucau reopened DELTASPIKE-1296:


> PropertyFileConfig doesn't work with internal extensions
> 
>
> Key: DELTASPIKE-1296
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1296
> Project: DeltaSpike
>  Issue Type: Bug
>Affects Versions: 1.8.0
>    Reporter: Romain Manni-Bucau
>Assignee: Mark Struberg
>
> We register PropertyFileConfig in AfterDeploymentValidation hook but 
> extensions potentially already read the config entries. Technically there is 
> probably no blocker to do it earlier and we should probably ensure all our 
> extensions read keys in AfterDeploymentValidation.
> My use case was a configured cron expression in the scheduler usage.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DELTASPIKE-1302) ThreadPoolManager: ExecutorService map is always empty

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266083#comment-16266083
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1302:


pushed the proposed impl, updated the doc with the config keys. Can you give it 
a try and let us know if it works good enough for you please?

> ThreadPoolManager: ExecutorService map is always empty
> --
>
> Key: DELTASPIKE-1302
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1302
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.8.0
>Reporter: Alonso Gonzalez
>Priority: Minor
>
> ThreadPoolManager contains a ConcurrentHashMap that maps from a pool name to 
> an ExecutorService. Unfortunately the map never gets populated. It's always 
> empty.
> I need this because I want to use a specific ExecutorService with @Futureable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)