Hi Roberto,

I'd drop it:

1. the default should stay the same as in G-config to have a consistent
behavior for end user I think and you should be able to have live updates
normally
2. I was not thinking to the webapp enrichment prefix but more to make
https://github.com/apache/tomee/blob/8fc8d8011c5155e7f47ebc162cb88124bf4ca06e/container/openejb-core/src/main/java/org/apache/openejb/config/DeploymentLoader.java#L1099
active by default and configurable. Concretely applyBuiltinExcludes takes
an include/exclude pair we should make configurable as in
https://github.com/apache/tomee/blob/8fc8d8011c5155e7f47ebc162cb88124bf4ca06e/container/openejb-core/src/main/java/org/apache/openejb/config/NewLoaderLogic.java#L445
or
https://github.com/apache/tomee/blob/8fc8d8011c5155e7f47ebc162cb88124bf4ca06e/container/openejb-core/src/main/java/org/apache/openejb/config/TldScanner.java#L337
but
with other key names for jar name prefixes (
openejb.scan.webapp.container.includes and
openejb.scan.webapp.container.excludes?). Default can use geronimo-* if we
ensure all default g-* are excluded except mp ones (what you started in
exclusions.list).

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>

2018-03-06 11:32 GMT+01:00 Roberto Cortez <radcor...@yahoo.com.invalid>:

>
> Hi again,
> I've pushed an update to the PR.
> Updated the LICENSE and NOTICE.Got rid of the MPClassLoaderEnricher.
> I still kept MPService, but it only reading and setting system properties
> to configure the environment. This is to prevent changes in
> system.properties that could mess the configuration. Still, if we prefer to
> just have these in there, I'm fine dropping the Service and place
> everything in system.properties.
> Cheers,Roberto    On Tuesday, March 6, 2018, 8:39:20 AM GMT, Mark Struberg
> <strub...@yahoo.de.INVALID> wrote:
>
>  Well, we did our best to not use types whose coercion lead to java8
> method calls which are not available in a java7 rt.jar.
>
> But the ONLY way you can _guarantee_ Java7 compatibility is to use a java7
> rt.jar during the release build.
> Everything else ended up being broken in some cases. You basically switch
> to 'JavaScript mode' where you will only blow up at runtime...
>
> LieGrue,
> strub
>
>
>
> > Am 06.03.2018 um 09:28 schrieb Romain Manni-Bucau <rmannibu...@gmail.com
> >:
> >
> > 2018-03-06 9:11 GMT+01:00 Mark Struberg <strub...@yahoo.de.invalid>:
> >
> >> The point is: you cannot pass the mp TCKs with Java7 but only with
> Java8.
> >>
> >> But if you run the release with Java8 then there is a high chance that
> the
> >> generated bytecode will not run on Java7 anymore.
> >> So until we drop Java7 officially (and move to a TomEE-7.1.0 version) we
> >> have to run the release build on Java7.
> >>
> >
> > That is no more true today since we worked to make it possible cleaning
> up
> > bad typings but the point is highly valid.
> >
> >
> >>
> >> That's why I suggested to only ship MP with TomEE8.
> >>
> >
> > +1
> >
> >
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>> Am 06.03.2018 um 08:30 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> 2018-03-06 8:22 GMT+01:00 Mark Struberg <strub...@yahoo.de.invalid>:
> >>>
> >>>> Did we already solve the Java8 question?
> >>>>
> >>>
> >>> Nop but not a blocker for java 8
> >>>
> >>>
> >>>> Because if we add MP then you cannot build with Java7 anymore.
> >>>>
> >>>
> >>> We fixed all the java8/7 build time incompatibilities so we can (now,
> >> agree
> >>> we need to ensure it is still the case but ATM we dont need buildchain
> to
> >>> do it).
> >>>
> >>>
> >>>>
> >>>> Lg strub
> >>>>
> >>>> Mit autocorrect gesendet
> >>>>
> >>>>> Am 05.03.2018 um 22:31 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> >>>>> :
> >>>>>
> >>>>> Le 5 mars 2018 22:07, "Jonathan Gallimore" <
> >> jonathan.gallim...@gmail.com>
> >>>> a
> >>>>> écrit :
> >>>>>
> >>>>> On Mon, Mar 5, 2018 at 9:03 PM, Romain Manni-Bucau <
> >>>> rmannibu...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Le 5 mars 2018 21:35, "Jonathan Gallimore" <
> >>>> jonathan.gallim...@gmail.com>
> >>>>>> a écrit :
> >>>>>>
> >>>>>> The name "MicroProfile" suggests an element of being small, so I'm
> not
> >>>>>> sure why we'd only add this to our biggest distribution and no where
> >>>> else.
> >>>>>> I've built the change (thanks for the help Roberto), and it adds
> >> <100KB
> >>>> to
> >>>>>> the binary. I'd definitely add it to Plus and Plume, but I think we
> >>>> should
> >>>>>> either add it web profile, or if we really don't want it in
> >> WebProfile,
> >>>> I
> >>>>>> see no harm in an extra flavour that is webprofile + microprofile.
> >>>>>>
> >>>>>>
> >>>>>> Ok for plume and plus for me, please not to WP.
> >>>>>>
> >>>>>
> >>>>> Would you be ok with the MP profile then? Seems like reasonable
> middle
> >>>>> ground. Without that, folks who want "Micro"Profile features would be
> >>>>> forced to use the biggest flavours.
> >>>>>
> >>>>>
> >>>>> Yep, as mentionned no issue to have a new distro ;).
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Open point: should it be switchable to off even if provided in case
> it
> >>>>>> breaks apps?
> >>>>>>
> >>>>>
> >>>>> I'm ok with that.
> >>>>>
> >>>>> Jon
> >>>>
> >>>>
> >>
> >>
>
>

Reply via email to