2016-11-10 17:31 GMT+01:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> Hey,
>
> one question:
> Currently the proxy handling just supports interfaces and doesn't use our
> proxy module.
> Doesn't it make sense to switch to our proxy module (which also supports
> abstract classes, interceptors)?
>
>
What an awesome throught (
https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/ProxyConfigurationLifecycle.java#L50
;))

"Issue" was: this should sit in core "before" in term of dependency the
proxy module. So we can support it but we need to detect it through
reflection in the extension to wrap the abstract classes and the handler
with the right annotations. Was not sure it does worth it but nothing
against.


>
> 2016-11-09 12:55 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
>
> > Pushed eveything I had and created the related jira for 1.8.0.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <https://github.com/
> > rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-11-08 21:28 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > Le 8 nov. 2016 18:59, "John D. Ament" <johndam...@apache.org> a écrit
> :
> > > >
> > > > I'm personally fine with that as a first pass but agree its going to
> > > cause
> > > > some issues because config is available pre-initialization of
> container
> > > > (e.g. there maybe no CDI available yet) as a result converters,
> filters
> > > may
> > > > not work.  Something to resolve at a later point.
> > > >
> > >
> > > The use case is runtime config - extension config being considered
> there
> > > as internal config or the app which can be hardcoded.
> > >
> > > I ll wait until tomorrow and if nobody shout will create tickets and
> push
> > > on master.
> > >
> > > > John
> > > >
> > > > On Tue, Nov 8, 2016 at 12:57 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > @ConfigProperty(converter) method was added and ConfigSource and
> > > > > ConfigFilter decoarated with @Source and @Filter are added to the
> > > config
> > > > > using cdi bean lookup after extension startup (= usable after CDI
> > > startup
> > > > > but without any META-INF/services and with all CDI features like
> > > injections
> > > > > and interceptors)
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE
> Factory
> > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > >
> > > > > 2016-11-08 18:52 GMT+01:00 John D. Ament <johndam...@apache.org>:
> > > > >
> > > > > > What's currently on your branch? I saw proxy.  Anything else?
> > > > > >
> > > > > > John
> > > > > >
> > > > > > On Tue, Nov 8, 2016 at 12:46 PM Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > if i open 3 tickets (convert, proxy, cdi source/filter) then
> push
> > > my
> > > > > > branch
> > > > > > > does it work?
> > > > > > >
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE
> > > Factory
> > > > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > > > >
> > > > > > > 2016-11-08 18:43 GMT+01:00 John D. Ament <
> johndam...@apache.org
> > >:
> > > > > > >
> > > > > > > > On Mon, Nov 7, 2016 at 12:41 PM Romain Manni-Bucau <
> > > > > > > rmannibu...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > 2016-11-07 17:56 GMT+01:00 Mark Struberg
> > > <strub...@yahoo.de.invalid
> > > > > > >:
> > > > > > > > >
> > > > > > > > > > yes the EAR case is a bit harder. Also OSGi is a bit
> > tricky.
> > > > > > > > > >
> > > > > > > > > > In my javaconfig proposal I have moved this out into a
> SPI
> > > which
> > > > > is
> > > > > > > > > > pluggable.
> > > > > > > > > > The only requirement is that you can get the config for
> > 'your
> > > > > > > > > application'
> > > > > > > > > > via ConfigProvider#getConfig().
> > > > > > > > > >
> > > > > > > > > > If this is internally done via a Map<ClassLoader, Config>
> > or
> > > a
> > > > > > > > > > Map<ConfigExtension, Config> or via a ThreadLocal is
> > totally
> > > up
> > > > > to
> > > > > > > the
> > > > > > > > > > implementation. For OSGi the ClassLoader might not be as
> > > good as
> > > > > > in a
> > > > > > > > WAR
> > > > > > > > > > or EAR. The ThreadLocal might blow up in an EAR on
> various
> > > > > > > containers,
> > > > > > > > > etc.
> > > > > > > > > > I fear there is no one-fits-all solution. We might
> provide
> > an
> > > > > impl
> > > > > > > > which
> > > > > > > > > > can be configured to use different strategies.
> > > > > > > > > >
> > > > > > > > > > The question is whether we like to make it depending on
> CDI
> > > or if
> > > > > > it
> > > > > > > > > > should also work purely in SE.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > I'd say this one is easy for deltaspike if we re-read the
> > > project
> > > > > > > > proposal
> > > > > > > > > (and BTW should be the same under EE ecosystem now, other
> > > choices
> > > > > > don't
> > > > > > > > > make much sense now in particuar for the config which
> should
> > be
> > > > > > > > > contextualized by something else than itself - ok off topic
> > > ;)).
> > > > > > > > >
> > > > > > > > > Concretely how do we move forward on these topics? I'm
> > > concerned to
> > > > > > get
> > > > > > > > > converter method in @ConfigProperty, the @Source/@Filter
> > > detection
> > > > > > and
> > > > > > > > > proxy support. Other mentionned features can be put on a
> > > backlog or
> > > > > > > > > forgotten I wouldn't cry.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > That's actually why i was saying separate JIRA tickets.
> Tackle
> > > the
> > > > > > > complex
> > > > > > > > needed stuff now, work on the more polish stuff later.
> > > > > > > >
> > > > > > > > Obviously, deltaspike should be focused on CDI runtimes.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > LieGrue,
> > > > > > > > > > strub
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > On Monday, 7 November 2016, 12:44, Romain Manni-Bucau <
> > > > > > > > > > rmannibu...@gmail.com> wrote:
> > > > > > > > > > > > added @Source and @Filter as markers (was breaking
> > > > > applications
> > > > > > > > > > otherwise),
> > > > > > > > > > > pushed the basic plain proxying too. Only tested with
> OWB
> > > for
> > > > > now
> > > > > > > but
> > > > > > > > > > seems
> > > > > > > > > > > not bad.
> > > > > > > > > > >
> > > > > > > > > > > The storage change is more impacting cause of ear case
> > > which is
> > > > > > not
> > > > > > > > > > > protable at all so wonder if we can do anything about
> it
> > > > > without
> > > > > > > > > breaking
> > > > > > > > > > > existing applications. Maybe we should just ensure we
> > don't
> > > > > leak
> > > > > > > the
> > > > > > > > > > > classloader as key for now to not break anyone (we can
> > > leak if
> > > > > > CDI
> > > > > > > > > > doesn't
> > > > > > > > > > > finish to start and the application is undeployed
> AFAIK).
> > > > > > > > > > >
> > > > > > > > > > > Adding the ConfigResolver as an instance in the CDI
> > > context (=
> > > > > a
> > > > > > > > bean)
> > > > > > > > > is
> > > > > > > > > > > still an option IMHO but can wait and is more an
> internal
> > > > > > > refactoring
> > > > > > > > > > than
> > > > > > > > > > > an API work.
> > > > > > > > > > >
> > > > > > > > > > > wdyt? What would be the next steps? JIRA for converter
> > > method,
> > > > > > > proxy
> > > > > > > > > > > feature and source/filter detection in CDI?
> > > > > > > > > > >
> > > > > > > > > > > Happy to also get some help on running it on other
> > > containers.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Romain Manni-Bucau
> > > > > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > > > > > > > > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > > > > > > > > <http://rmannibucau.wordpress.com> | Github
> > > > > > > > > > > <https://github.com/rmannibucau> |
> > > > > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> |
> > > JavaEE
> > > > > > > Factory
> > > > > > > > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > > > > > > > >
> > > > > > > > > > > 2016-11-07 9:39 GMT+01:00 Romain Manni-Bucau <
> > > > > > > rmannibu...@gmail.com
> > > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > >>  In the spirit of sharing and trying to move forward I
> > > > > started a
> > > > > > > > > branch
> > > > > > > > > > on
> > > > > > > > > > >>  my github fork: https://github.com/
> > > > > > rmannibucau/deltaspike/tree/
> > > > > > > > > > >>  fb/config-rework
> > > > > > > > > > >>
> > > > > > > > > > >>  For now it includes 1 ("easy") and 5 (pre 2 storage
> but
> > > will
> > > > > be
> > > > > > > > > > > part of
> > > > > > > > > > >>  the refactoring "2" normally since we'll not break
> this
> > > API).
> > > > > > > > > > >>
> > > > > > > > > > >>  About 5 there is the question of the detection. By
> type
> > > is
> > > > > > enough
> > > > > > > > > > >>  technically but wonder if we should introduce @Source
> > and
> > > > > > @Filter
> > > > > > > > > just
> > > > > > > > > > as
> > > > > > > > > > >>  markers to ensure we don't also detect SPI sources
> and
> > > > > filters
> > > > > > > > which
> > > > > > > > > > > are
> > > > > > > > > > >>  likely CDI beans in a lot of apps.
> > > > > > > > > > >>  Feedback welcomed ^^ :).
> > > > > > > > > > >>
> > > > > > > > > > >>  Once done, next step will be to add 3 then try to do
> 2.
> > > If
> > > > > all
> > > > > > is
> > > > > > > > > good
> > > > > > > > > > we
> > > > > > > > > > >>  can work on the jira tickets.
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>  Romain Manni-Bucau
> > > > > > > > > > >>  @rmannibucau <https://twitter.com/rmannibucau> |
> Blog
> > > > > > > > > > >>  <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > > > > > > > > > >>  <http://rmannibucau.wordpress.com> | Github
> > > > > > > > > > >>  <https://github.com/rmannibucau> | LinkedIn
> > > > > > > > > > >>  <https://www.linkedin.com/in/rmannibucau> | JavaEE
> > > Factory
> > > > > > > > > > >>  <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > > > > > > > >
> > > > > > > > > > >>
> > > > > > > > > > >>  2016-11-06 21:40 GMT+01:00 Mark Struberg
> > > > > > > <strub...@yahoo.de.invalid
> > > > > > > > > >:
> > > > > > > > > > >>
> > > > > > > > > > >>>  +1 for moving the Config out into an own module.
> It's
> > > the
> > > > > best
> > > > > > > we
> > > > > > > > > > > can do
> > > > > > > > > > >>>  for now. The JSR will likely take a bit to evolve
> and
> > > until
> > > > > > then
> > > > > > > > we
> > > > > > > > > > can
> > > > > > > > > > > use
> > > > > > > > > > >>>  what we have in DeltaSpike. Just a bit cleaned up.
> > > > > > > > > > >>>
> > > > > > > > > > >>>  LieGrue,
> > > > > > > > > > >>>  strub
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>  PS: a single ticket is by far enough imo.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>  > On Sunday, 6 November 2016, 21:28, John D. Ament
> > > > > > > > > > > <johndam...@apache.org>
> > > > > > > > > > >>>  wrote:
> > > > > > > > > > >>>  > > Some thoughts in line.
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  > On Sun, Nov 6, 2016 at 3:16 PM Romain Manni-Bucau
> <
> > > > > > > > > > >>>  rmannibu...@gmail.com>
> > > > > > > > > > >>>  > wrote:
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >>  Hi guys
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >>  sent it some times ago - ok, a long time ago now
> > ;)
> > > -
> > > > > but
> > > > > > > > > > > will retry
> > > > > > > > > > >>>  with
> > > > > > > > > > >>>  >>  few more details now.
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >>  Goal: I'd like to rework a bit our configuration
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  > How does this relate, if at all, to Mark's
> proposal
> > > for
> > > > > > config
> > > > > > > > > > > on
> > > > > > > > > > >>>  geronimo?
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >>  Proposals (no particular order but numbered to
> let
> > > it be
> > > > > > > > > > > referenced):
> > > > > > > > > > >>>  >>  1. Add converter to @ConfigProperty (cdi lookup
> or
> > > > > > fallback
> > > > > > > > > > > on
> > > > > > > > > > >>>  >>  newInstance() probably)
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  > +1
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >>  2. remove the map storage we have and replace it
> > by
> > > > > > > > > > >>>  >>  2.a. a thread local during the boot
> ConfigResolver
> > > would
> > > > > > use
> > > > > > > > > > >>>  >>  2.b. a config bean for the runtime (BeanProvider
> > or
> > > > > > > > > > > CDI.current()
> > > > > > > > > > >>>  allow to
> > > > > > > > > > >>>  >>  get it easily)
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  > +1000 I hate the static methods for users.
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >>  3. add an interface/abstract class based
> > > configuration
> > > > > > > > > > > "à la
> > > > > > > > > > >>>  > owner"
> > > > > > > > > > >>>  >>  (probably reusing @ConfigProperty)
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  > I've been thinking about this as well.  Sounds
> like
> > a
> > > good
> > > > > > fit
> > > > > > > > > > > for
> > > > > > > > > > >>>  partial
> > > > > > > > > > >>>  > bean.
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >>  4. extract config in its own module to let it be
> > > reused
> > > > > > more
> > > > > > > > > > > widely
> > > > > > > > > > >>>  without
> > > > > > > > > > >>>  >>  bringing all ds core
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  > I like the idea.  But I think the real problem is
> > > defining
> > > > > > > what
> > > > > > > > is
> > > > > > > > > > > core
> > > > > > > > > > >>>  vs
> > > > > > > > > > >>>  > what is a module.  To me, core should be a
> > lightweight
> > > > > > > > component.
> > > > > > > > > > > We've
> > > > > > > > > > >>>  > stuck some extra stuff in there that can be a pain
> > > > > > sometimes.
> > > > > > > > May
> > > > > > > > > > > be
> > > > > > > > > > >>>  worth
> > > > > > > > > > >>>  > an entirely separate thread.
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >>  5. support during bootstrap the detection of
> > > converters
> > > > > > and
> > > > > > > > > > > sources
> > > > > > > > > > >>>  (not
> > > > > > > > > > >>>  >>  only propertyfile ones) and add them in the
> > runtime
> > > > > config
> > > > > > > > > > > added in
> > > > > > > > > > >>>  2.b
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  > Well, this kind of works today.  Using a property
> > > source
> > > > > > > > provider,
> > > > > > > > > > > I was
> > > > > > > > > > >>>  > able to create a archaius config source and have
> it
> > > > > > discovered
> > > > > > > > > > > pretty
> > > > > > > > > > >>>  early
> > > > > > > > > > >>>  > on.
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >>  2. implies we don't use the config in extension
> > > > > > > > > > > constructor (which
> > > > > > > > > > >>>  > should
> > > > > > > > > > >>>  >>  be fine) and that we can cleanup the thread
> local
> > > after
> > > > > > CDI
> > > > > > > > > > > startup
> > > > > > > > > > >>>  (here
> > > > > > > > > > >>>  >>  we can have few options to enforce this cleanup
> > like
> > > > > using
> > > > > > > > > > >>>  >>  AfterDeploymentValidation by default + probably
> > > either
> > > > > > some
> > > > > > > > > > > container
> > > > > > > > > > >>>  >>  dependent solutions or at least a
> > > > > > > > > > > ServletContextListener#context
> > > > > > > > > > >>>  Destroyed
> > > > > > > > > > >>>  >>  for the case deployment fails)
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >>  Excepted the usability (converter option,
> > > extraction in
> > > > > a
> > > > > > > > > > > dedicated
> > > > > > > > > > >>>  module)
> > > > > > > > > > >>>  >>  the goal is to not do any concurrence to CDI
> > lookup
> > > > > > mecanism
> > > > > > > > > > > and stay
> > > > > > > > > > >>>  100%
> > > > > > > > > > >>>  >>  aligned on it.
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >>  In term of usability the fact to be able to
> have a
> > > real
> > > > > > CDI
> > > > > > > > > > > source
> > > > > > > > > > >>>  DTO for
> > > > > > > > > > >>>  >>  runtime and reuse default ones (system
> properties,
> > > > > > > properties
> > > > > > > > > > > in
> > > > > > > > > > >>>  classpath,
> > > > > > > > > > >>>  >>  etc..) for the extension itself (internal
> > > application
> > > > > > > > > > > configuration)
> > > > > > > > > > >>>  is a
> > > > > > > > > > >>>  >>  huge gain IMHO.
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >>  Wdyt? Any blocker?
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  > Would you be able to get the ideas into JIRA as a
> > few
> > > > > > > different
> > > > > > > > > > > tickets?
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >>  This would likely lead to a 1.8.
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >>  Romain Manni-Bucau
> > > > > > > > > > >>>  >>  @rmannibucau <https://twitter.com/rmannibucau>
> |
> > > Blog
> > > > > > > > > > >>>  >>  <https://blog-rmannibucau.rhcloud.com> | Old
> Blog
> > > > > > > > > > >>>  >>  <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > > > >>>  >>  https://github.com/rmannibucau> |
> > > > > > > > > > >>>  >>  LinkedIn <https://www.linkedin.com/in/
> rmannibucau
> > >
> > > |
> > > > > > > > > > > JavaEE Factory
> > > > > > > > > > >>>  >>  <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > > > > > > > >>>  >>
> > > > > > > > > > >>>  >
> > > > > > > > > > >>>
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
>

Reply via email to