Re: Other MP Specs @ Geronimo?

[David Blevins]

> On Sep 7, 2017, at 5:35 PM, John D. Ament  wrote:
> 
> The reason I'm hesitant to look at XBean, it seems to be focused on a single 
> target (which is good for a sub-project).  It would start to confuse things 
> to make more stuff XBean.

Can you elaborate on what you mean by single target?  I’m happy to give the 
history behind XBean, but the long and short of it is it was largely made by 
OpenEJB, ActiveMQ and ServiceMix as a place to share code we thought each other 
might want to reuse.  A lot of it wasn’t used by Geronimo till later.  Nearly 
all of it is unrelated and goes across the board.  It’s the closest Apache has 
gotten to an EE commons.

 - xbean-spring = Configuration library for Spring apps that want to use custom 
xml

 Used by: ActiveMQ, ServiceMix

 - xbean-finder = Annotation scanning library

 Used by: OpenEJB, Geronimo, ServiceMix, ActiveMQ, Aries,
  Netflix Governator, Netflix Zuul, OPS4j, CrateDB

 - xbean-blueprint = OSGi blueprint related stuff

 Used by: Geronimio, ServiceMix, ActiveMQ, Aries, Fabric8,
  Osgiliath

 - xbean-naming = JNDI implementation

 Used by: Geronimo, OpenEJB, ServiceMix, Ode, Nuxeo.org,
  Osgiliath

 - xbean-reflect = Lightweight pojo creator/injector

 Used by: OpenEJB, Geronimo, ServiceMix, Plexus, BatchEE,
  Meecrowave, Fabric8, Sonatype Nexus, JOnAS, OPS4j,
  Osgiliath, DataTorrent, more


> Plus its a kind of odd name, I'm guessing the X is for XML.

“Odd name” is a fine enough reason for me.  I certainly prefer that over 
arguing what XBean is or isn’t, cause then I feel like I need to give a history 
lesson.  XBean *is* “app server commons”.  It has no other purpose than that.

There are better names.  Let’s definitely use them if we can find them.  My 
preference would be for us to keep using xbean-* when we can’t think of a 
better name.


-David

Re: Other MP Specs @ Geronimo?

[John D. Ament]

On Thu, Sep 7, 2017 at 7:59 PM David Blevins 
wrote:

> > On Sep 4, 2017, at 4:56 PM, John D. Ament  wrote:
> >
> > So I want to pick back up at least with fault tolerance.  Would anyone
> be opposed to starting up a repo on it?  I'm thinking of the name
> "Safeguard" so that it would either be "org.apache.safeguard" or
> "org.apache.geronimo.safeguard" as group id in maven (xbean uses the
> former, config the latter).
>
> I have a strong preference for “org.apache.safeguard" over
> “org.apache.geronimo.safeguard”.  We have 14 years of Google search results
> to work against and a few million developers brains that say Geronimo is an
> app server.  Every time we put “Geronimo” on something, it’s a strike
> against Hammok, Meecrowave and TomEE and any MP implementation that may
> want to use it but not confuse the world that “Geronimo is back".
>

My preference is to keep "org.apache.safeguard" as well.  I've created the
base skeleton with "org.apache.geronimo.safeguard" but not sure it'll
stay.  Would be good to get a solid response on naming recommendations, so
we'll see.  Most other sub-projects just use their own name.


>
> If we do want a parent package, I repeat we can use org.apache.xbean if we
> like.  It was meant for common reusable stuff.  We do not need to shackle
> ourselves with any self-imposed restrictions like “xbean needs to be all
> released at once”.  That was only done out of laziness.
>
>
The reason I'm hesitant to look at XBean, it seems to be focused on a
single target (which is good for a sub-project).  It would start to confuse
things to make more stuff XBean.  Plus its a kind of odd name, I'm guessing
the X is for XML.


>
> -David
>
>
>
>
>
>
>
>

[jira] [Updated] (GERONIMO-6579) Support injecting Supplier

[John D. Ament (JIRA)]

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

John D. Ament updated GERONIMO-6579:

Component/s: Config

> Support injecting Supplier
> -
>
> Key: GERONIMO-6579
> URL: https://issues.apache.org/jira/browse/GERONIMO-6579
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Config
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: Config_1.0
>
>
> Mark raised this on the MP Spec.  I think it would be a great idea to 
> prototype this on geronimo side first.  We can add support for injecting 
> Supplier and perhaps do the following:
> - Defer look up of the value (don't cache it) until the get method is called
> - If the property is not set, use the default value
> - If the default value is the standard unconfigured value, return null.
> - Otherwise convert the value.



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

[jira] [Updated] (GERONIMO-6579) Support injecting Supplier

[John D. Ament (JIRA)]

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

John D. Ament updated GERONIMO-6579:

Fix Version/s: Config_1.0

> Support injecting Supplier
> -
>
> Key: GERONIMO-6579
> URL: https://issues.apache.org/jira/browse/GERONIMO-6579
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Config
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: Config_1.0
>
>
> Mark raised this on the MP Spec.  I think it would be a great idea to 
> prototype this on geronimo side first.  We can add support for injecting 
> Supplier and perhaps do the following:
> - Defer look up of the value (don't cache it) until the get method is called
> - If the property is not set, use the default value
> - If the default value is the standard unconfigured value, return null.
> - Otherwise convert the value.



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

[jira] [Updated] (GERONIMO-6571) Add root element to beans.xml

[John D. Ament (JIRA)]

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

John D. Ament updated GERONIMO-6571:

Fix Version/s: Config_1.0

> Add root element to beans.xml
> -
>
> Key: GERONIMO-6571
> URL: https://issues.apache.org/jira/browse/GERONIMO-6571
> Project: Geronimo
>  Issue Type: Wish
>  Security Level: public(Regular issues) 
>  Components: Config
>Reporter: Rudy De Busscher
>Assignee: John D. Ament
>Priority: Minor
> Fix For: Config_1.0
>
>
> When deployed on WildFly (Weld), the deploy fails because the beans.xml 
> contains only comment.
> It should be empty or have the root element 
> See Weld bug  https://issues.jboss.org/browse/WELD-2408



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

[jira] [Resolved] (GERONIMO-6576) Implement MP Config 1.1

[John D. Ament (JIRA)]

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

John D. Ament resolved GERONIMO-6576.
-
Resolution: Fixed

> Implement MP Config 1.1
> ---
>
> Key: GERONIMO-6576
> URL: https://issues.apache.org/jira/browse/GERONIMO-6576
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Config
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: Config_1.0
>
>
> Implement the MP Config 1.1 Feature Set
> - Primitive Support - GERONIMO-6575
> - Injection of properties by injection point name
> - URL Converter
> - Property names of a given config source
> Plus anything else that may come up.



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

[jira] [Updated] (GERONIMO-6576) Implement MP Config 1.1

[John D. Ament (JIRA)]

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

John D. Ament updated GERONIMO-6576:

Fix Version/s: Config_1.0

> Implement MP Config 1.1
> ---
>
> Key: GERONIMO-6576
> URL: https://issues.apache.org/jira/browse/GERONIMO-6576
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Config
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: Config_1.0
>
>
> Implement the MP Config 1.1 Feature Set
> - Primitive Support - GERONIMO-6575
> - Injection of properties by injection point name
> - URL Converter
> - Property names of a given config source
> Plus anything else that may come up.



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

[jira] [Updated] (GERONIMO-6577) [config] injection of @ConfigProperty Provider is broken

[John D. Ament (JIRA)]

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

John D. Ament updated GERONIMO-6577:

Fix Version/s: Config_1.0

> [config] injection of @ConfigProperty Provider is broken
> ---
>
> Key: GERONIMO-6577
> URL: https://issues.apache.org/jira/browse/GERONIMO-6577
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Config
>Reporter: Mark Struberg
>Assignee: John D. Ament
> Fix For: Config_1.0
>
>
> {code}
> @Inject
> @ConfigProperty(name="bla")
> private Provider dynamicValue;
> {code}
> is broken; blows up with Missing converter for 'bla' from Field Injection 
> Point, field name : ...



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

[jira] [Updated] (GERONIMO-6566) Implement MicroProfile Config

[John D. Ament (JIRA)]

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

John D. Ament updated GERONIMO-6566:

Fix Version/s: Config_1.0

> Implement MicroProfile Config
> -
>
> Key: GERONIMO-6566
> URL: https://issues.apache.org/jira/browse/GERONIMO-6566
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Config
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: Config_1.0
>
>
> A long time ago we've discussed to start a EE configuration project for 
> Application configuration. This now got made close to become the basis for a 
> standard in the MicroProfile movement. 
> The Config approach is based on Gerhards and my work in OWB and DeltaSpike, 
> but sadly got made a standard outside of the ASF. 
> But at least the implementation should live on over here.



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

[jira] [Updated] (GERONIMO-6575) Register primitives by default (using same converters)

[John D. Ament (JIRA)]

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

John D. Ament updated GERONIMO-6575:

Fix Version/s: Config_1.0

> Register primitives by default (using same converters)
> --
>
> Key: GERONIMO-6575
> URL: https://issues.apache.org/jira/browse/GERONIMO-6575
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Config
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: Config_1.0
>
>
> Allow primitives to be used without manual registration.



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

Re: Other MP Specs @ Geronimo?

[David Blevins]

> On Sep 4, 2017, at 4:56 PM, John D. Ament  wrote:
> 
> So I want to pick back up at least with fault tolerance.  Would anyone be 
> opposed to starting up a repo on it?  I'm thinking of the name "Safeguard" so 
> that it would either be "org.apache.safeguard" or 
> "org.apache.geronimo.safeguard" as group id in maven (xbean uses the former, 
> config the latter).

I have a strong preference for “org.apache.safeguard" over 
“org.apache.geronimo.safeguard”.  We have 14 years of Google search results to 
work against and a few million developers brains that say Geronimo is an app 
server.  Every time we put “Geronimo” on something, it’s a strike against 
Hammok, Meecrowave and TomEE and any MP implementation that may want to use it 
but not confuse the world that “Geronimo is back".

If we do want a parent package, I repeat we can use org.apache.xbean if we 
like.  It was meant for common reusable stuff.  We do not need to shackle 
ourselves with any self-imposed restrictions like “xbean needs to be all 
released at once”.  That was only done out of laziness.


-David

Re: Releasing Config tomorrow?

[Romain Manni-Bucau]

+1

Le 7 sept. 2017 16:03, "John D. Ament"  a écrit :

> Hi All,
>
> I'm about to start the release process for MP Config Spec 1.1.  Would
> anyone be opposed to starting a release vote on GConfig 1.0 tomorrow?  Or
> first thing next week?
>
> John
>

Releasing Config tomorrow?

[John D. Ament]

Hi All,

I'm about to start the release process for MP Config Spec 1.1.  Would
anyone be opposed to starting a release vote on GConfig 1.0 tomorrow?  Or
first thing next week?

John