[GitHub] [openwebbeans] philippkunz commented on a change in pull request #28: Cdi parameter resolver

[GitBox]

philippkunz commented on a change in pull request #28:
URL: https://github.com/apache/openwebbeans/pull/28#discussion_r439770518



##
File path: 
webbeans-junit5/src/main/java/org/apache/openwebbeans/junit5/internal/CdiExtension.java
##
@@ -172,4 +182,76 @@ private void doClose(final SeContainer container)
 }
 });
 }
+
+private Cdi getCdiConfig(ExtensionContext extensionContext)
+{
+return AnnotationUtils.findAnnotation(extensionContext.getElement(), 
Cdi.class).orElse(null);
+}
+
+private SeContainer getContainer()
+{
+if (testInstanceContainer != null)
+{
+return testInstanceContainer;
+}
+else
+{
+return reusableContainer;
+}
+}
+
+@Override
+public boolean supportsParameter(ParameterContext parameterContext, 
ExtensionContext extensionContext)
+throws ParameterResolutionException
+{
+final Cdi config = 
extensionContext.getParent().map(this::getCdiConfig).orElse(null);
+if (config == null || !config.injectParameters())
+{
+return false;
+}
+
+final SeContainer container = getContainer();
+if (container == null)
+{
+return false;
+}
+
+Bean bean = resolveParameterBean(container, parameterContext, 
extensionContext);
+return bean != null;
+}
+
+@Override
+public Object resolveParameter(ParameterContext parameterContext, 
ExtensionContext extensionContext)
+throws ParameterResolutionException
+{
+final SeContainer container = getContainer();
+if (container == null)
+{
+return false;
+}
+
+Bean bean = resolveParameterBean(container, parameterContext, 
extensionContext);
+BeanManager beanManager = container.getBeanManager();
+CreationalContext creationalContext = 
beanManager.createCreationalContext(bean);
+creationalContexts.add(creationalContext);
+return beanManager.getReference(bean, 
parameterContext.getParameter().getType(), creationalContext);
+}
+
+private Bean resolveParameterBean(SeContainer container, 
ParameterContext parameterContext, ExtensionContext extensionContext)
+{
+BeanManager beanManager = container.getBeanManager();
+Set> beans = beanManager.getBeans(
+parameterContext.getParameter().getType(),
+getQualifiers(parameterContext.getParameter()));
+return beanManager.resolve(beans);

Review comment:
   @rmannibucau suggested to consider caching the resolution results. I'm 
not yet sure exactly which would be the most promising approach or if it is 
really worth it or if the bean manager is optimized already and fast enough.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [openwebbeans] philippkunz commented on a change in pull request #28: Cdi parameter resolver

[GitBox]

philippkunz commented on a change in pull request #28:
URL: https://github.com/apache/openwebbeans/pull/28#discussion_r439770221



##
File path: 
webbeans-junit5/src/main/java/org/apache/openwebbeans/junit5/internal/CdiExtension.java
##
@@ -172,4 +182,76 @@ private void doClose(final SeContainer container)
 }
 });
 }
+
+private Cdi getCdiConfig(ExtensionContext extensionContext)
+{
+return AnnotationUtils.findAnnotation(extensionContext.getElement(), 
Cdi.class).orElse(null);
+}
+
+private SeContainer getContainer()
+{
+if (testInstanceContainer != null)
+{
+return testInstanceContainer;
+}
+else
+{
+return reusableContainer;
+}
+}
+
+@Override
+public boolean supportsParameter(ParameterContext parameterContext, 
ExtensionContext extensionContext)
+throws ParameterResolutionException
+{
+final Cdi config = 
extensionContext.getParent().map(this::getCdiConfig).orElse(null);

Review comment:
   `extensionContext` here is a MethodExtensionContext while 
`extensionContext` in beforeAll is a ClassExtensionContext which is the parent. 
Methods always have classes as parents and there also will always be a parent 
class for a method.
   However, I'm not fully satisfied that this will work with all situations 
such as dynamic tests, nested test classes, or whatever else. For a beginning I 
tend to opt that this is no worse than before but it can be further elaborated 
as desired.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [openwebbeans] philippkunz commented on a change in pull request #28: Cdi parameter resolver

[GitBox]

philippkunz commented on a change in pull request #28:
URL: https://github.com/apache/openwebbeans/pull/28#discussion_r439769304



##
File path: webbeans-junit5/src/main/java/org/apache/openwebbeans/junit5/Cdi.java
##
@@ -80,6 +80,11 @@
  */
 boolean disableDiscovery() default false;
 
+/**
+ * @return {@code true} to enable JUnit parameter resolution with CDI 
beans or {@code false} otherwise.
+ */
+boolean injectParameters() default true;

Review comment:
   as suggested by @rmannibucau 
   





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [openwebbeans] philippkunz commented on a change in pull request #28: Cdi parameter resolver

[GitBox]

philippkunz commented on a change in pull request #28:
URL: https://github.com/apache/openwebbeans/pull/28#discussion_r439769215



##
File path: webbeans-junit5/pom.xml
##
@@ -76,17 +76,9 @@
 
 default-test
 
-true
-
-
-
-perclass
-test
-
-test
-
-
-**/perclass/*
+
+**/reusable/*
+

Review comment:
   almost unrelated but otherwise the new test would have not been picked 
up by surefire





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [openwebbeans] philippkunz opened a new pull request #28: Cdi parameter resolver

[GitBox]

philippkunz opened a new pull request #28:
URL: https://github.com/apache/openwebbeans/pull/28


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Romain Manni-Bucau]

Then not sure which place you have in mind to fail?
An alternative could have been to do exclusions on the url.tostring but it
would break current existing apps which is not an option for this thing
IMHO.
Do you have anything in mind?

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



Le sam. 13 juin 2020 à 20:41, Mark Struberg  a
écrit :

> No, we did have File in OWB-1.0 and 1.1. And killed that because we got
> problems because not all classpath elemts are file based.
> Examples are some app servers which have even some internal protocols.
> like webjar for example in EARs in WebLogic (yes, there are some peeps who
> use OWB in weblogic, because it's so much faster than the default CDI
> container!). It also might happen in Arquillian for example, or other
> purely memory based scenarios where the JAR never exists on disk..
> This was the reason we switched for URL. Anything file based is
> counterproductive in this location.
>
> LieGrue,
> strub
>
>
> > Am 13.06.2020 um 20:32 schrieb Romain Manni-Bucau  >:
> >
> > Yes and no IMHO. Strictly speaking you are perfectly
> > right,
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery#registerBeanArchives
> > should handle File and not URL and do the filtering there (and fail if
> > needed)
> > but
> org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery#filterExcludedJars
> > is protected and therefore we should respect this signature so sounds
> like
> > we must do it in the registerBeanArchives and keep a map File -> URL to
> > reserve it in filter method. Is it your proposal Mark?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le sam. 13 juin 2020 à 20:13, Mark Struberg 
> a
> > écrit :
> >
> >>
> >>
> >>> Am 13.06.2020 um 19:37 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
>  e.2)
>  if (file == null) {
>    throw new IllegalArgumentException(
>  Why? Let's log a WARN, but why blow up? xbean only supports jar: and
> >> file:
>  protocols. Anything other will just not be excluded. So what?
> 
> >>>
> >>> Blow up cause we don't know how to handle it and it is unexpected -
> until
> >>> we refine the exact protocol like jrt:// (but this particular one must
> >> not
> >>> happen here).
> >>> Typically if you silently ignore it then you don't do what is expected
> at
> >>> 100% so better fail when we don't know since it is not a supported case
> >> so
> >>> behavior will be undefined.
> >>> To give you an example: you use jpms to make your app "pseudo native"
> >> then
> >>> scanning is no more done and the app is broken so IMHO best we can do
> is
> >>> fail and point on the two solutions: exclude if ok or use another impl
> >>> (shrinkwrap for the referenced jira).
> >>
> >> But this is totally the wrong location to stop handling this case.
> >>
> >> This method is just for filtering out classpath entries we know must NOT
> >> be scanned.
> >> So the default is to _not_ remove classpath entries if we are unsure.
> >>
> >> IF it turns out that the app cannot handle it, then we will handle this
> in
> >> the Deployer anyway.
> >> I'd rather be really defensive here: the method is for removing
> classpath
> >> entries it KNOWS must not be handled. If it is unsure, then not remove
> >> anything.
> >> Wrong location to complain about any bad protocol!
> >>
> >> LieGrue,
> >> strub
>
>

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Romain Manni-Bucau]

Yes and no IMHO. Strictly speaking you are perfectly
right, 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery#registerBeanArchives
should handle File and not URL and do the filtering there (and fail if
needed)
but 
org.apache.webbeans.corespi.scanner.AbstractMetaDataDiscovery#filterExcludedJars
is protected and therefore we should respect this signature so sounds like
we must do it in the registerBeanArchives and keep a map File -> URL to
reserve it in filter method. Is it your proposal Mark?

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



Le sam. 13 juin 2020 à 20:13, Mark Struberg  a
écrit :

>
>
> > Am 13.06.2020 um 19:37 schrieb Romain Manni-Bucau  >:
> >
> >> e.2)
> >> if (file == null) {
> >>throw new IllegalArgumentException(
> >> Why? Let's log a WARN, but why blow up? xbean only supports jar: and
> file:
> >> protocols. Anything other will just not be excluded. So what?
> >>
> >
> > Blow up cause we don't know how to handle it and it is unexpected - until
> > we refine the exact protocol like jrt:// (but this particular one must
> not
> > happen here).
> > Typically if you silently ignore it then you don't do what is expected at
> > 100% so better fail when we don't know since it is not a supported case
> so
> > behavior will be undefined.
> > To give you an example: you use jpms to make your app "pseudo native"
> then
> > scanning is no more done and the app is broken so IMHO best we can do is
> > fail and point on the two solutions: exclude if ok or use another impl
> > (shrinkwrap for the referenced jira).
>
> But this is totally the wrong location to stop handling this case.
>
> This method is just for filtering out classpath entries we know must NOT
> be scanned.
> So the default is to _not_ remove classpath entries if we are unsure.
>
> IF it turns out that the app cannot handle it, then we will handle this in
> the Deployer anyway.
> I'd rather be really defensive here: the method is for removing classpath
> entries it KNOWS must not be handled. If it is unsure, then not remove
> anything.
> Wrong location to complain about any bad protocol!
>
> LieGrue,
> strub

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Mark Struberg]

> Am 13.06.2020 um 19:37 schrieb Romain Manni-Bucau :
> 
>> e.2)
>> if (file == null) {
>>throw new IllegalArgumentException(
>> Why? Let's log a WARN, but why blow up? xbean only supports jar: and file:
>> protocols. Anything other will just not be excluded. So what?
>> 
> 
> Blow up cause we don't know how to handle it and it is unexpected - until
> we refine the exact protocol like jrt:// (but this particular one must not
> happen here).
> Typically if you silently ignore it then you don't do what is expected at
> 100% so better fail when we don't know since it is not a supported case so
> behavior will be undefined.
> To give you an example: you use jpms to make your app "pseudo native" then
> scanning is no more done and the app is broken so IMHO best we can do is
> fail and point on the two solutions: exclude if ok or use another impl
> (shrinkwrap for the referenced jira).

But this is totally the wrong location to stop handling this case.

This method is just for filtering out classpath entries we know must NOT be 
scanned.
So the default is to _not_ remove classpath entries if we are unsure.

IF it turns out that the app cannot handle it, then we will handle this in the 
Deployer anyway.
I'd rather be really defensive here: the method is for removing classpath 
entries it KNOWS must not be handled. If it is unsure, then not remove anything.
Wrong location to complain about any bad protocol!

LieGrue,
strub

[jira] [Resolved] (OWB-1329) Remove openwebbeans-maven module

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved OWB-1329.
-
Resolution: Fixed

> Remove openwebbeans-maven module
> 
>
> Key: OWB-1329
> URL: https://issues.apache.org/jira/browse/OWB-1329
> Project: OpenWebBeans
>  Issue Type: Task
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 2.0.18
>
>
> Module is now provided by maven-shade-plugin OOTB



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

[jira] [Resolved] (MEECROWAVE-248) Upgrade to Log4j 2.13.3

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-248.
---
Resolution: Fixed

> Upgrade to Log4j 2.13.3
> ---
>
> Key: MEECROWAVE-248
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-248
> Project: Meecrowave
>  Issue Type: Task
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.10
>
>




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

[jira] [Resolved] (MEECROWAVE-247) Upgrade to Johnzon 1.2.7

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-247.
---
Resolution: Fixed

> Upgrade to  Johnzon 1.2.7
> -
>
> Key: MEECROWAVE-247
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-247
> Project: Meecrowave
>  Issue Type: Task
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.10
>
>




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

[jira] [Resolved] (MEECROWAVE-246) Upgrade to OpenWebbeans 2.0.17

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-246.
---
Resolution: Fixed

> Upgrade to OpenWebbeans 2.0.17
> --
>
> Key: MEECROWAVE-246
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-246
> Project: Meecrowave
>  Issue Type: Task
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.10
>
>




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

[jira] [Resolved] (MEECROWAVE-249) Upgrade to OpenJPA 3.1.1

[Romain Manni-Bucau (Jira)]

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

Romain Manni-Bucau resolved MEECROWAVE-249.
---
Resolution: Fixed

> Upgrade to OpenJPA 3.1.1
> 
>
> Key: MEECROWAVE-249
> URL: https://issues.apache.org/jira/browse/MEECROWAVE-249
> Project: Meecrowave
>  Issue Type: Task
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 1.2.10
>
>




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

[jira] [Created] (OWB-1329) Remove openwebbeans-maven module

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created OWB-1329:
---

 Summary: Remove openwebbeans-maven module
 Key: OWB-1329
 URL: https://issues.apache.org/jira/browse/OWB-1329
 Project: OpenWebBeans
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 2.0.18


Module is now provided by maven-shade-plugin OOTB



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

[jira] [Created] (MEECROWAVE-249) Upgrade to OpenJPA 3.1.1

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-249:
-

 Summary: Upgrade to OpenJPA 3.1.1
 Key: MEECROWAVE-249
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-249
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.10






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

[jira] [Created] (MEECROWAVE-248) Upgrade to Log4j 2.13.3

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-248:
-

 Summary: Upgrade to Log4j 2.13.3
 Key: MEECROWAVE-248
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-248
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.10






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

[jira] [Created] (MEECROWAVE-247) Upgrade to Johnzon 1.2.7

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-247:
-

 Summary: Upgrade to  Johnzon 1.2.7
 Key: MEECROWAVE-247
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-247
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.10






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

[jira] [Created] (MEECROWAVE-246) Upgrade to OpenWebbeans 2.0.17

[Romain Manni-Bucau (Jira)]

Romain Manni-Bucau created MEECROWAVE-246:
-

 Summary: Upgrade to OpenWebbeans 2.0.17
 Key: MEECROWAVE-246
 URL: https://issues.apache.org/jira/browse/MEECROWAVE-246
 Project: Meecrowave
  Issue Type: Task
Reporter: Romain Manni-Bucau
Assignee: Romain Manni-Bucau
 Fix For: 1.2.10






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

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Romain Manni-Bucau]

Le sam. 13 juin 2020 à 19:29, Mark Struberg  a
écrit :

> Wow, there are sooo many different things going on.
>
> a.) also -1 for 'obvious' - nearly redundant - docs.
>
> b.) In Geronimo there are about 5..7 active folks. Plus the people from
> the TomEE project which do reviews and give precious feedback.
>
> c.) In OWB we also had lots of active people: Romain, Thomas, me,
> Reinhard, Arne, Gurkan, Jean-Louis, Matt Benson, Gerhard Petracek, John
> Ament, Daniel Dias, etc
> It's just that the intensity of being active did change a lot for those
> people over time. Coming and going.
>
> d.) Of course Gurkan you are highly welcome back!
>
> e.) yes, there are MANY questions about this whole filterExcludedJars
> method in the AbstractMetadataDiscovery!
>
> e.1) why do we have some hardcoded exclude gor geronimo spec jars at all?
> This sounds like a bad thing.
>
> e.2)
> if (file == null) {
> throw new IllegalArgumentException(
> Why? Let's log a WARN, but why blow up? xbean only supports jar: and file:
> protocols. Anything other will just not be excluded. So what?
>

Blow up cause we don't know how to handle it and it is unexpected - until
we refine the exact protocol like jrt:// (but this particular one must not
happen here).
Typically if you silently ignore it then you don't do what is expected at
100% so better fail when we don't know since it is not a supported case so
behavior will be undefined.
To give you an example: you use jpms to make your app "pseudo native" then
scanning is no more done and the app is broken so IMHO best we can do is
fail and point on the two solutions: exclude if ok or use another impl
(shrinkwrap for the referenced jira).


>
> e.3)
> if (file.exists())
> Bloody why? ;) Would this ever work for jar:// protocol? Is this really OS
> independent? There are tons of classpath elements which are just in memory!
> I drove my brain mad to NOT have any protocol dependent code in OWB and
> now we even go for file level ops? That's just wrong. Away with this
> file.exists I'd say!
>
>
+1 to drop, does not make sense.


> LieGrue,
> strub
>
>
> > Am 13.06.2020 um 16:45 schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
> >
> > +1 in general, Gurkan
> >
> > however, we should focus on the most important things only
> > everyone of us is working on many OS projects and its quite hard to write
> > many docu as its very time consuming.
> > i would like to have at least docus on class level (we can also skip them
> > if the class is a POJO or no brainer) - we should really try e.g. to
> > document SPI classes
> >
> > but really -1 for boilerplate docu like the constructor doku (initializes
> > this class) or inhertiDoc.
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > Virenfrei.
> > www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > Am Sa., 13. Juni 2020 um 13:22 Uhr schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com>:
> >
> >> Updated this fix by failing if url is null with a message saying to
> either
> >> change the scanner or add the file to exclusions.
> >> Can anyone review it please before next release (2.0.18)?
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Blog
> >>  | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn  | Book
> >> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>
> >>
> >> Le sam. 13 juin 2020 à 12:01, Gurkan Erdogdu 
> a
> >> écrit :
> >>
> 
>  This is wrong, what does make you think that? I know you left for a
> >> very
>  long time and missed quite a lot of things
> >>>
> >>> I have been following most of the mailing lists even if I am not able
> to
> >>> contribute.
> >>>
> >>>
> >>> but typically most of xbean is
>  not decided by these 3 people but was decided way earlier and we get
> >> like
>  5-6 people interacting regularly intercommunities (thinking to ee but
>  osgi/karaf and standlaone too). Not huge but clearly not a one man
> >>> project.
> 
> >>> I am not just talking about something special to XBean. General
> >>> observation.
> >>>
> >>> Side note here is that it is not the right list to discuss that and not
> >> the
>  right thread too probably (we shouldnt mix topics in threads IMHO).
> >>>
> >>> Thank you for the advice.
> >>>
> >>> I do not want to continue the discussion. You are always having to say
> >>> something.
> >>> Good luck to you on these projects even in OWB.
> >>> Cheers
> >>> Gurkan
> >>>
> >>>
> >>> On Sat, Jun 13, 2020 at 12:39 PM Romain Manni-Bucau <
> >> rmannibu...@gmail.com
> 
> >>> wrote:
> >>>
>  Le sam. 13 juin 2020 à 10:54, Gurkan Erdogdu <
> 

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Mark Struberg]

Wow, there are sooo many different things going on.

a.) also -1 for 'obvious' - nearly redundant - docs.

b.) In Geronimo there are about 5..7 active folks. Plus the people from the 
TomEE project which do reviews and give precious feedback.

c.) In OWB we also had lots of active people: Romain, Thomas, me, Reinhard, 
Arne, Gurkan, Jean-Louis, Matt Benson, Gerhard Petracek, John Ament, Daniel 
Dias, etc
It's just that the intensity of being active did change a lot for those people 
over time. Coming and going. 

d.) Of course Gurkan you are highly welcome back!

e.) yes, there are MANY questions about this whole filterExcludedJars method in 
the AbstractMetadataDiscovery!

e.1) why do we have some hardcoded exclude gor geronimo spec jars at all? This 
sounds like a bad thing.

e.2) 
if (file == null) {
throw new IllegalArgumentException(
Why? Let's log a WARN, but why blow up? xbean only supports jar: and file: 
protocols. Anything other will just not be excluded. So what? 

e.3)
if (file.exists())
Bloody why? ;) Would this ever work for jar:// protocol? Is this really OS 
independent? There are tons of classpath elements which are just in memory! 
I drove my brain mad to NOT have any protocol dependent code in OWB and now we 
even go for file level ops? That's just wrong. Away with this file.exists I'd 
say!

LieGrue,
strub


> Am 13.06.2020 um 16:45 schrieb Thomas Andraschko 
> :
> 
> +1 in general, Gurkan
> 
> however, we should focus on the most important things only
> everyone of us is working on many OS projects and its quite hard to write
> many docu as its very time consuming.
> i would like to have at least docus on class level (we can also skip them
> if the class is a POJO or no brainer) - we should really try e.g. to
> document SPI classes
> 
> but really -1 for boilerplate docu like the constructor doku (initializes
> this class) or inhertiDoc.
> 
> 
> Virenfrei.
> www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> Am Sa., 13. Juni 2020 um 13:22 Uhr schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
> 
>> Updated this fix by failing if url is null with a message saying to either
>> change the scanner or add the file to exclusions.
>> Can anyone review it please before next release (2.0.18)?
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>> 
>> 
>> Le sam. 13 juin 2020 à 12:01, Gurkan Erdogdu  a
>> écrit :
>> 
 
 This is wrong, what does make you think that? I know you left for a
>> very
 long time and missed quite a lot of things
>>> 
>>> I have been following most of the mailing lists even if I am not able to
>>> contribute.
>>> 
>>> 
>>> but typically most of xbean is
 not decided by these 3 people but was decided way earlier and we get
>> like
 5-6 people interacting regularly intercommunities (thinking to ee but
 osgi/karaf and standlaone too). Not huge but clearly not a one man
>>> project.
 
>>> I am not just talking about something special to XBean. General
>>> observation.
>>> 
>>> Side note here is that it is not the right list to discuss that and not
>> the
 right thread too probably (we shouldnt mix topics in threads IMHO).
>>> 
>>> Thank you for the advice.
>>> 
>>> I do not want to continue the discussion. You are always having to say
>>> something.
>>> Good luck to you on these projects even in OWB.
>>> Cheers
>>> Gurkan
>>> 
>>> 
>>> On Sat, Jun 13, 2020 at 12:39 PM Romain Manni-Bucau <
>> rmannibu...@gmail.com
 
>>> wrote:
>>> 
 Le sam. 13 juin 2020 à 10:54, Gurkan Erdogdu >> 
>>> a
 écrit :
 
> If you want to revert , you can...
> But Xbean method returns null and throwing NPE is not a good way to
>>> go...
> 
 
 Contract makes it respected. If you run in another env you setup
>> another
 impl.
 Side note being ignoring silently an error is worse IMO.
 
 
 
> From my understanding looking to those projects and even OWB, most of
>>> the
> decisions in these projects are only decided by one or two
 persons(probably
> internally) but not with the community, this is not the Apache way of
> managing projects.
> 
 
 This is wrong, what does make you think that? I know you left for a
>> very
 long time and missed quite a lot of things but typically most of xbean
>> is
 not decided by these 3 people but was decided way earlier and we get
>> like
 5-6 people interacting regularly intercommunities (thinking to ee but
 

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Thomas Andraschko]

+1 in general, Gurkan

however, we should focus on the most important things only
everyone of us is working on many OS projects and its quite hard to write
many docu as its very time consuming.
i would like to have at least docus on class level (we can also skip them
if the class is a POJO or no brainer) - we should really try e.g. to
document SPI classes

but really -1 for boilerplate docu like the constructor doku (initializes
this class) or inhertiDoc.


Virenfrei.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Am Sa., 13. Juni 2020 um 13:22 Uhr schrieb Romain Manni-Bucau <
rmannibu...@gmail.com>:

> Updated this fix by failing if url is null with a message saying to either
> change the scanner or add the file to exclusions.
> Can anyone review it please before next release (2.0.18)?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le sam. 13 juin 2020 à 12:01, Gurkan Erdogdu  a
> écrit :
>
> > >
> > > This is wrong, what does make you think that? I know you left for a
> very
> > > long time and missed quite a lot of things
> >
> > I have been following most of the mailing lists even if I am not able to
> > contribute.
> >
> >
> > but typically most of xbean is
> > > not decided by these 3 people but was decided way earlier and we get
> like
> > > 5-6 people interacting regularly intercommunities (thinking to ee but
> > > osgi/karaf and standlaone too). Not huge but clearly not a one man
> > project.
> > >
> > I am not just talking about something special to XBean. General
> > observation.
> >
> > Side note here is that it is not the right list to discuss that and not
> the
> > > right thread too probably (we shouldnt mix topics in threads IMHO).
> >
> > Thank you for the advice.
> >
> > I do not want to continue the discussion. You are always having to say
> > something.
> > Good luck to you on these projects even in OWB.
> > Cheers
> > Gurkan
> >
> >
> > On Sat, Jun 13, 2020 at 12:39 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > Le sam. 13 juin 2020 à 10:54, Gurkan Erdogdu  >
> > a
> > > écrit :
> > >
> > > > If you want to revert , you can...
> > > > But Xbean method returns null and throwing NPE is not a good way to
> > go...
> > > >
> > >
> > > Contract makes it respected. If you run in another env you setup
> another
> > > impl.
> > > Side note being ignoring silently an error is worse IMO.
> > >
> > >
> > >
> > > > From my understanding looking to those projects and even OWB, most of
> > the
> > > > decisions in these projects are only decided by one or two
> > > persons(probably
> > > > internally) but not with the community, this is not the Apache way of
> > > > managing projects.
> > > >
> > >
> > > This is wrong, what does make you think that? I know you left for a
> very
> > > long time and missed quite a lot of things but typically most of xbean
> is
> > > not decided by these 3 people but was decided way earlier and we get
> like
> > > 5-6 people interacting regularly intercommunities (thinking to ee but
> > > osgi/karaf and standlaone too). Not huge but clearly not a one man
> > project.
> > >
> > > Side note here is that it is not the right list to discuss that and not
> > the
> > > right thread too probably (we shouldnt mix topics in threads IMHO).
> > >
> > >
> > > > It is impossible for me to contribute such projects which are handled
> > > this
> > > > way...
> > > >
> > > > Cheers
> > > >
> > > > Gurkan
> > > >
> > > > On 13 Jun 2020 Sat at 09:18 Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Don't want to look mad or bad but I personally have a hard time to
> > > > convert
> > > > > such statement to action Gurkan.
> > > > > Basically most of this code is not that complex so self explanatory
> > for
> > > > me
> > > > > - but also true I never read comments when contributing to project
> > I'm
> > > > not
> > > > > committer in cause they generally brings you in a wrong direction
> > IMHO.
> > > > > Are you missing some architecture design doc maybe?
> > > > >
> > > > > Side note: back on this commit, if it is linked to the ticket I
> > > > commented,
> > > > > it should be reverted right?
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book

Re: Cdi Parameter Injection

[Romain Manni-Bucau]

Hi Philipp,

A few notes:

1. You can do PR on github if it helps
2. I'd cache the resolution of supports (if true) to reuse it to get the
instance, speeds up things in a suite
3. We need a @CdiInjection marker (whatever name) otherwise we can break
injections for things which are beans but also injected with another
extension quite easily (mode=all makes it common). If no marker we can use
your impl but the marker should enable to skip it so either something
like @Cdiinjection(true|false) or @SkipCdi maybe?

Hope it makes sense.

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



Le sam. 13 juin 2020 à 15:34, Philipp Kunz  a
écrit :

> Hi,
>
> Wouldn't it be nice, if CDI would also resolve method parameters?
> See patch.
>
> Regards,
> Philipp
>

Cdi Parameter Injection

[Philipp Kunz]

Hi,

Wouldn't it be nice, if CDI would also resolve method parameters?
See patch.

Regards,
Philipp
diff --git a/webbeans-junit5/pom.xml b/webbeans-junit5/pom.xml
index 23f18161b..0e0807621 100644
--- a/webbeans-junit5/pom.xml
+++ b/webbeans-junit5/pom.xml
@@ -76,17 +76,9 @@
 
 default-test
 
-true
-
-
-
-perclass
-test
-
-test
-
-
-**/perclass/*
+
+**/reusable/*
+
 
 
 
@@ -96,7 +88,9 @@
 test
 
 
-**/reusable/*
+
+**/reusable/*
+
 
 
 
diff --git a/webbeans-junit5/src/main/java/org/apache/openwebbeans/junit5/internal/CdiExtension.java b/webbeans-junit5/src/main/java/org/apache/openwebbeans/junit5/internal/CdiExtension.java
index 382b90c7a..94e5ed52a 100644
--- a/webbeans-junit5/src/main/java/org/apache/openwebbeans/junit5/internal/CdiExtension.java
+++ b/webbeans-junit5/src/main/java/org/apache/openwebbeans/junit5/internal/CdiExtension.java
@@ -24,6 +24,9 @@ import org.junit.jupiter.api.extension.AfterEachCallback;
 import org.junit.jupiter.api.extension.BeforeAllCallback;
 import org.junit.jupiter.api.extension.BeforeEachCallback;
 import org.junit.jupiter.api.extension.ExtensionContext;
+import org.junit.jupiter.api.extension.ParameterContext;
+import org.junit.jupiter.api.extension.ParameterResolutionException;
+import org.junit.jupiter.api.extension.ParameterResolver;
 import org.junit.platform.commons.util.AnnotationUtils;
 
 import javax.enterprise.context.spi.CreationalContext;
@@ -34,19 +37,22 @@ import javax.enterprise.inject.spi.BeanManager;
 import javax.enterprise.inject.spi.InjectionTarget;
 import java.io.Closeable;
 import java.io.IOException;
+import java.lang.annotation.Annotation;
 import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Parameter;
 import java.util.ArrayList;
+import java.util.Arrays;
 import java.util.Collection;
 import java.util.Objects;
 import java.util.function.Supplier;
 import java.util.stream.Stream;
 
 // todo: enhance the setup to be thread safe? see Meecrowave ClassLoaderLock class and friends
-public class CdiExtension implements BeforeAllCallback, AfterAllCallback, BeforeEachCallback, AfterEachCallback
+public class CdiExtension implements BeforeAllCallback, AfterAllCallback, BeforeEachCallback, AfterEachCallback, ParameterResolver
 {
 private static SeContainer reusableContainer;
 
-private SeContainer container;
+private SeContainer testInstanceContainer;
 private Collection> creationalContexts = new ArrayList<>();
 private Closeable[] onStop;
 
@@ -104,32 +110,34 @@ public class CdiExtension implements BeforeAllCallback, AfterAllCallback, Before
 .peek(Supplier::get)
 .filter(Objects::nonNull)
 .toArray(Closeable[]::new);
+SeContainer container = initializer.initialize();
 if (reusable)
 {
-reusableContainer = initializer.initialize();
+reusableContainer = container;
 Runtime.getRuntime().addShutdownHook(new Thread(
 () -> doClose(reusableContainer), getClass().getName() + "-shutdown"));
 }
 else
 {
-container = initializer.initialize();
+testInstanceContainer = container;
 }
 }
 
 @Override
 public void afterAll(final ExtensionContext extensionContext)
 {
-if (container != null)
+if (testInstanceContainer != null)
 {
-doClose(container);
-container = null;
+doClose(testInstanceContainer);
+testInstanceContainer = null;
 }
 }
 
 @Override
 public void beforeEach(final ExtensionContext extensionContext)
 {
-if (container == null && reusableContainer == null)
+SeContainer container = getContainer();
+if (container == null)
 {
 return;
 }
@@ -137,7 +145,7 @@ public class CdiExtension implements BeforeAllCallback, AfterAllCallback, Before
 {
 testInstances.getAllInstances().stream().distinct().forEach(instance ->
 {
-final BeanManager manager = (container == null ? reusableContainer : container).getBeanManager();
+final BeanManager manager = container.getBeanManager();
 

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Romain Manni-Bucau]

Updated this fix by failing if url is null with a message saying to either
change the scanner or add the file to exclusions.
Can anyone review it please before next release (2.0.18)?

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



Le sam. 13 juin 2020 à 12:01, Gurkan Erdogdu  a
écrit :

> >
> > This is wrong, what does make you think that? I know you left for a very
> > long time and missed quite a lot of things
>
> I have been following most of the mailing lists even if I am not able to
> contribute.
>
>
> but typically most of xbean is
> > not decided by these 3 people but was decided way earlier and we get like
> > 5-6 people interacting regularly intercommunities (thinking to ee but
> > osgi/karaf and standlaone too). Not huge but clearly not a one man
> project.
> >
> I am not just talking about something special to XBean. General
> observation.
>
> Side note here is that it is not the right list to discuss that and not the
> > right thread too probably (we shouldnt mix topics in threads IMHO).
>
> Thank you for the advice.
>
> I do not want to continue the discussion. You are always having to say
> something.
> Good luck to you on these projects even in OWB.
> Cheers
> Gurkan
>
>
> On Sat, Jun 13, 2020 at 12:39 PM Romain Manni-Bucau  >
> wrote:
>
> > Le sam. 13 juin 2020 à 10:54, Gurkan Erdogdu 
> a
> > écrit :
> >
> > > If you want to revert , you can...
> > > But Xbean method returns null and throwing NPE is not a good way to
> go...
> > >
> >
> > Contract makes it respected. If you run in another env you setup another
> > impl.
> > Side note being ignoring silently an error is worse IMO.
> >
> >
> >
> > > From my understanding looking to those projects and even OWB, most of
> the
> > > decisions in these projects are only decided by one or two
> > persons(probably
> > > internally) but not with the community, this is not the Apache way of
> > > managing projects.
> > >
> >
> > This is wrong, what does make you think that? I know you left for a very
> > long time and missed quite a lot of things but typically most of xbean is
> > not decided by these 3 people but was decided way earlier and we get like
> > 5-6 people interacting regularly intercommunities (thinking to ee but
> > osgi/karaf and standlaone too). Not huge but clearly not a one man
> project.
> >
> > Side note here is that it is not the right list to discuss that and not
> the
> > right thread too probably (we shouldnt mix topics in threads IMHO).
> >
> >
> > > It is impossible for me to contribute such projects which are handled
> > this
> > > way...
> > >
> > > Cheers
> > >
> > > Gurkan
> > >
> > > On 13 Jun 2020 Sat at 09:18 Romain Manni-Bucau 
> > > wrote:
> > >
> > > > Don't want to look mad or bad but I personally have a hard time to
> > > convert
> > > > such statement to action Gurkan.
> > > > Basically most of this code is not that complex so self explanatory
> for
> > > me
> > > > - but also true I never read comments when contributing to project
> I'm
> > > not
> > > > committer in cause they generally brings you in a wrong direction
> IMHO.
> > > > Are you missing some architecture design doc maybe?
> > > >
> > > > Side note: back on this commit, if it is linked to the ticket I
> > > commented,
> > > > it should be reverted right?
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le ven. 12 juin 2020 à 21:45, Gurkan Erdogdu <
> cgurkanerdo...@gmail.com
> > >
> > > a
> > > > écrit :
> > > >
> > > > > Hi
> > > > > I am looking at projects in Apache Geronimo and OWB side such as
> > XBean,
> > > > > Meecrowave, Microprofile, Arthur etc. to contribute more.
> > > > > I have observed that most of the source code has very small code
> > > comments
> > > > > and most of them are driven by a very small group of contributors.
> > > > > It is really hard to contribute to these projects without some bit
> of
> > > > > understanding of the source code. The important key idea behind the
> > > > Apache
> > > > > Projects are community and projects need to be driven by the
> > community.
> > > > To
> > > > > extend the community around projects, we need to more care about
> the
> > > > > source codes, documentation, guides etc.
> > > > > I know that this type of stuff is time consuming but also
> important.
> > > > > I just want to share my observations 

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Gurkan Erdogdu]

>
> This is wrong, what does make you think that? I know you left for a very
> long time and missed quite a lot of things

I have been following most of the mailing lists even if I am not able to
contribute.


but typically most of xbean is
> not decided by these 3 people but was decided way earlier and we get like
> 5-6 people interacting regularly intercommunities (thinking to ee but
> osgi/karaf and standlaone too). Not huge but clearly not a one man project.
>
I am not just talking about something special to XBean. General observation.

Side note here is that it is not the right list to discuss that and not the
> right thread too probably (we shouldnt mix topics in threads IMHO).

Thank you for the advice.

I do not want to continue the discussion. You are always having to say
something.
Good luck to you on these projects even in OWB.
Cheers
Gurkan


On Sat, Jun 13, 2020 at 12:39 PM Romain Manni-Bucau 
wrote:

> Le sam. 13 juin 2020 à 10:54, Gurkan Erdogdu  a
> écrit :
>
> > If you want to revert , you can...
> > But Xbean method returns null and throwing NPE is not a good way to go...
> >
>
> Contract makes it respected. If you run in another env you setup another
> impl.
> Side note being ignoring silently an error is worse IMO.
>
>
>
> > From my understanding looking to those projects and even OWB, most of the
> > decisions in these projects are only decided by one or two
> persons(probably
> > internally) but not with the community, this is not the Apache way of
> > managing projects.
> >
>
> This is wrong, what does make you think that? I know you left for a very
> long time and missed quite a lot of things but typically most of xbean is
> not decided by these 3 people but was decided way earlier and we get like
> 5-6 people interacting regularly intercommunities (thinking to ee but
> osgi/karaf and standlaone too). Not huge but clearly not a one man project.
>
> Side note here is that it is not the right list to discuss that and not the
> right thread too probably (we shouldnt mix topics in threads IMHO).
>
>
> > It is impossible for me to contribute such projects which are handled
> this
> > way...
> >
> > Cheers
> >
> > Gurkan
> >
> > On 13 Jun 2020 Sat at 09:18 Romain Manni-Bucau 
> > wrote:
> >
> > > Don't want to look mad or bad but I personally have a hard time to
> > convert
> > > such statement to action Gurkan.
> > > Basically most of this code is not that complex so self explanatory for
> > me
> > > - but also true I never read comments when contributing to project I'm
> > not
> > > committer in cause they generally brings you in a wrong direction IMHO.
> > > Are you missing some architecture design doc maybe?
> > >
> > > Side note: back on this commit, if it is linked to the ticket I
> > commented,
> > > it should be reverted right?
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le ven. 12 juin 2020 à 21:45, Gurkan Erdogdu  >
> > a
> > > écrit :
> > >
> > > > Hi
> > > > I am looking at projects in Apache Geronimo and OWB side such as
> XBean,
> > > > Meecrowave, Microprofile, Arthur etc. to contribute more.
> > > > I have observed that most of the source code has very small code
> > comments
> > > > and most of them are driven by a very small group of contributors.
> > > > It is really hard to contribute to these projects without some bit of
> > > > understanding of the source code. The important key idea behind the
> > > Apache
> > > > Projects are community and projects need to be driven by the
> community.
> > > To
> > > > extend the community around projects, we need to more care about the
> > > > source codes, documentation, guides etc.
> > > > I know that this type of stuff is time consuming but also important.
> > > > I just want to share my observations around these very cool projects.
> > > > Regards.
> > > > Gurkan
> > > >
> > > >
> > > >
> > > > On Wed, Jun 10, 2020 at 9:58 AM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hmm,
> > > > >
> > > > > Have to admit I always use maven to run TCK and I use Intellij so
> not
> > > > that
> > > > > sure.
> > > > > Maybe something you can give a try is to only open tck module and
> > close
> > > > > other modules to ensure eclipse m2 resolves it through the m2 repo
> > but
> > > > > without any guarantee :s.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | 

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Romain Manni-Bucau]

Le sam. 13 juin 2020 à 10:54, Gurkan Erdogdu  a
écrit :

> If you want to revert , you can...
> But Xbean method returns null and throwing NPE is not a good way to go...
>

Contract makes it respected. If you run in another env you setup another
impl.
Side note being ignoring silently an error is worse IMO.



> From my understanding looking to those projects and even OWB, most of the
> decisions in these projects are only decided by one or two persons(probably
> internally) but not with the community, this is not the Apache way of
> managing projects.
>

This is wrong, what does make you think that? I know you left for a very
long time and missed quite a lot of things but typically most of xbean is
not decided by these 3 people but was decided way earlier and we get like
5-6 people interacting regularly intercommunities (thinking to ee but
osgi/karaf and standlaone too). Not huge but clearly not a one man project.

Side note here is that it is not the right list to discuss that and not the
right thread too probably (we shouldnt mix topics in threads IMHO).


> It is impossible for me to contribute such projects which are handled this
> way...
>
> Cheers
>
> Gurkan
>
> On 13 Jun 2020 Sat at 09:18 Romain Manni-Bucau 
> wrote:
>
> > Don't want to look mad or bad but I personally have a hard time to
> convert
> > such statement to action Gurkan.
> > Basically most of this code is not that complex so self explanatory for
> me
> > - but also true I never read comments when contributing to project I'm
> not
> > committer in cause they generally brings you in a wrong direction IMHO.
> > Are you missing some architecture design doc maybe?
> >
> > Side note: back on this commit, if it is linked to the ticket I
> commented,
> > it should be reverted right?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 12 juin 2020 à 21:45, Gurkan Erdogdu 
> a
> > écrit :
> >
> > > Hi
> > > I am looking at projects in Apache Geronimo and OWB side such as XBean,
> > > Meecrowave, Microprofile, Arthur etc. to contribute more.
> > > I have observed that most of the source code has very small code
> comments
> > > and most of them are driven by a very small group of contributors.
> > > It is really hard to contribute to these projects without some bit of
> > > understanding of the source code. The important key idea behind the
> > Apache
> > > Projects are community and projects need to be driven by the community.
> > To
> > > extend the community around projects, we need to more care about the
> > > source codes, documentation, guides etc.
> > > I know that this type of stuff is time consuming but also important.
> > > I just want to share my observations around these very cool projects.
> > > Regards.
> > > Gurkan
> > >
> > >
> > >
> > > On Wed, Jun 10, 2020 at 9:58 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Hmm,
> > > >
> > > > Have to admit I always use maven to run TCK and I use Intellij so not
> > > that
> > > > sure.
> > > > Maybe something you can give a try is to only open tck module and
> close
> > > > other modules to ensure eclipse m2 resolves it through the m2 repo
> but
> > > > without any guarantee :s.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le mer. 10 juin 2020 à 08:38, Gurkan Erdogdu <
> cgurkanerdo...@gmail.com
> > >
> > > a
> > > > écrit :
> > > >
> > > > > Hi Romain
> > > > > I will look into geronimo-xbean.
> > > > > In the mean time, I have a question:
> > > > > I try to run TestNG plugin in Eclipse but because of javax ->
> jakarta
> > > > maven
> > > > > shading, I am not able to launch the tests via this plugin. It
> throws
> > > > > errors like
> > > > >
> > > > > INFO: CDI-TCK Specification version: null
> > > > > java.lang.NoClassDefFoundError: javax/el/ExpressionFactory
> > > > >
> > > > > Do you have any experience on this? I like to use this plugin to
> see
> > > > > visually the tests
> > > > > Regards.
> > > > > Gurkan
> > > > >
> > > > >
> > > > > On Wed, Jun 10, 2020 at 9:09 AM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Gurkan,
> > > > > >
> > > > > > Any way to test it and maybe harness it in geronimo xbean?
> > > > > > Typically it can only happen if the 

Re: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Gurkan Erdogdu]

If you want to revert , you can...
But Xbean method returns null and throwing NPE is not a good way to go...

>From my understanding looking to those projects and even OWB, most of the
decisions in these projects are only decided by one or two persons(probably
internally) but not with the community, this is not the Apache way of
managing projects.

It is impossible for me to contribute such projects which are handled this
way...

Cheers

Gurkan

On 13 Jun 2020 Sat at 09:18 Romain Manni-Bucau 
wrote:

> Don't want to look mad or bad but I personally have a hard time to convert
> such statement to action Gurkan.
> Basically most of this code is not that complex so self explanatory for me
> - but also true I never read comments when contributing to project I'm not
> committer in cause they generally brings you in a wrong direction IMHO.
> Are you missing some architecture design doc maybe?
>
> Side note: back on this commit, if it is linked to the ticket I commented,
> it should be reverted right?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 12 juin 2020 à 21:45, Gurkan Erdogdu  a
> écrit :
>
> > Hi
> > I am looking at projects in Apache Geronimo and OWB side such as XBean,
> > Meecrowave, Microprofile, Arthur etc. to contribute more.
> > I have observed that most of the source code has very small code comments
> > and most of them are driven by a very small group of contributors.
> > It is really hard to contribute to these projects without some bit of
> > understanding of the source code. The important key idea behind the
> Apache
> > Projects are community and projects need to be driven by the community.
> To
> > extend the community around projects, we need to more care about the
> > source codes, documentation, guides etc.
> > I know that this type of stuff is time consuming but also important.
> > I just want to share my observations around these very cool projects.
> > Regards.
> > Gurkan
> >
> >
> >
> > On Wed, Jun 10, 2020 at 9:58 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hmm,
> > >
> > > Have to admit I always use maven to run TCK and I use Intellij so not
> > that
> > > sure.
> > > Maybe something you can give a try is to only open tck module and close
> > > other modules to ensure eclipse m2 resolves it through the m2 repo but
> > > without any guarantee :s.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 10 juin 2020 à 08:38, Gurkan Erdogdu  >
> > a
> > > écrit :
> > >
> > > > Hi Romain
> > > > I will look into geronimo-xbean.
> > > > In the mean time, I have a question:
> > > > I try to run TestNG plugin in Eclipse but because of javax -> jakarta
> > > maven
> > > > shading, I am not able to launch the tests via this plugin. It throws
> > > > errors like
> > > >
> > > > INFO: CDI-TCK Specification version: null
> > > > java.lang.NoClassDefFoundError: javax/el/ExpressionFactory
> > > >
> > > > Do you have any experience on this? I like to use this plugin to see
> > > > visually the tests
> > > > Regards.
> > > > Gurkan
> > > >
> > > >
> > > > On Wed, Jun 10, 2020 at 9:09 AM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Gurkan,
> > > > >
> > > > > Any way to test it and maybe harness it in geronimo xbean?
> > > > > Typically it can only happen if the URL is wrongly formatted (means
> > we
> > > > > should port a fix in xbean too) or the protocol is not supported
> > > (likely
> > > > > means a missing exclusion or new protocol handling in xbean).
> > > > > I saw some issues with .so in the past in tests but never managed
> to
> > > > > reproduce it  and I know jrt brings a new protocol but thought we
> > > > excluded
> > > > > it by default so if can confirm this case and if you have a few
> > > pointers
> > > > it
> > > > > would be great, I would be happy to do the work in xbean about it.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Book
> > > > > <
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance

Re: [VOTE][RESULT] Release Apache OpenWebBeans-2.0.17

[Mark Struberg]

Hi!

Sorry for taking a bit longer.

With my own +1 we got the following VOTE result:

+1: Daniel, Romain, Gurkan, Reinhard, Mark

I'll continue with the release process.

txs and LieGrue,
strub



> Am 07.06.2020 um 23:30 schrieb Mark Struberg :
> 
> hi!
> 
> I'd like to call a VOTE on releasing Apache OpenWebBeans-2.0.17
> 
> The following tickets have been resolved:
> 
> Bug
> 
> [OWB-1214 ] - Package 
> annotation access is fragile
> Task
> 
> [OWB-1322 ] - SLF4J 
> integration workaround for log4j2-slf4j implementation which can fail in NPE 
> on java >= 9
> [OWB-1323 ] - Upgrade to asm8
> [OWB-1324 ] - Support maven 
> shade 3.2.3
> [OWB-1325 ] - Provide a spy 
> flavor of ClassDefiningService
> [OWB-1326 ] - Bean#isNullable 
> is ignored since CDI-1.1.
> 
> 
> 
> The staging repo is
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/
>  
> 
> 
> commit in our repo is 20d2b83390996007873abb2338a8b1fb61a55ceb
> 
> The source release can be found in 
> https://repository.apache.org/content/repositories/orgapacheopenwebbeans-1062/org/apache/openwebbeans/openwebbeans/2.0.17/
>  
> 
> 
> sha1 is 192bd3654375640ac5ceb365e728bba67bed16b4
> 
> 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: [openwebbeans] branch master updated: OWB-1328 NPE in AbstractMetaDataFactory

[Romain Manni-Bucau]

Don't want to look mad or bad but I personally have a hard time to convert
such statement to action Gurkan.
Basically most of this code is not that complex so self explanatory for me
- but also true I never read comments when contributing to project I'm not
committer in cause they generally brings you in a wrong direction IMHO.
Are you missing some architecture design doc maybe?

Side note: back on this commit, if it is linked to the ticket I commented,
it should be reverted right?

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



Le ven. 12 juin 2020 à 21:45, Gurkan Erdogdu  a
écrit :

> Hi
> I am looking at projects in Apache Geronimo and OWB side such as XBean,
> Meecrowave, Microprofile, Arthur etc. to contribute more.
> I have observed that most of the source code has very small code comments
> and most of them are driven by a very small group of contributors.
> It is really hard to contribute to these projects without some bit of
> understanding of the source code. The important key idea behind the Apache
> Projects are community and projects need to be driven by the community. To
> extend the community around projects, we need to more care about the
> source codes, documentation, guides etc.
> I know that this type of stuff is time consuming but also important.
> I just want to share my observations around these very cool projects.
> Regards.
> Gurkan
>
>
>
> On Wed, Jun 10, 2020 at 9:58 AM Romain Manni-Bucau 
> wrote:
>
> > Hmm,
> >
> > Have to admit I always use maven to run TCK and I use Intellij so not
> that
> > sure.
> > Maybe something you can give a try is to only open tck module and close
> > other modules to ensure eclipse m2 resolves it through the m2 repo but
> > without any guarantee :s.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 10 juin 2020 à 08:38, Gurkan Erdogdu 
> a
> > écrit :
> >
> > > Hi Romain
> > > I will look into geronimo-xbean.
> > > In the mean time, I have a question:
> > > I try to run TestNG plugin in Eclipse but because of javax -> jakarta
> > maven
> > > shading, I am not able to launch the tests via this plugin. It throws
> > > errors like
> > >
> > > INFO: CDI-TCK Specification version: null
> > > java.lang.NoClassDefFoundError: javax/el/ExpressionFactory
> > >
> > > Do you have any experience on this? I like to use this plugin to see
> > > visually the tests
> > > Regards.
> > > Gurkan
> > >
> > >
> > > On Wed, Jun 10, 2020 at 9:09 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Hi Gurkan,
> > > >
> > > > Any way to test it and maybe harness it in geronimo xbean?
> > > > Typically it can only happen if the URL is wrongly formatted (means
> we
> > > > should port a fix in xbean too) or the protocol is not supported
> > (likely
> > > > means a missing exclusion or new protocol handling in xbean).
> > > > I saw some issues with .so in the past in tests but never managed to
> > > > reproduce it  and I know jrt brings a new protocol but thought we
> > > excluded
> > > > it by default so if can confirm this case and if you have a few
> > pointers
> > > it
> > > > would be great, I would be happy to do the work in xbean about it.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > -- Forwarded message -
> > > > De : 
> > > > Date: mer. 10 juin 2020 à 07:11
> > > > Subject: [openwebbeans] branch master updated: OWB-1328 NPE in
> > > > AbstractMetaDataFactory
> > > > To: comm...@openwebbeans.apache.org  >
> > > >
> > > >
> > > > This is an automated email from the ASF dual-hosted git repository.
> > > >
> > > > gerdogdu pushed a commit to branch master
> > > > in repository https://gitbox.apache.org/repos/asf/openwebbeans.git
> > > >
> > > >
> > > > The following commit(s) were added to refs/heads/master by this push:
> > > >  new b812c6f  OWB-1328 NPE in AbstractMetaDataFactory
> > > >  new ff4c809  Merge branch 'master' of
> > > > https://github.com/apache/openwebbeans
> > > > b812c6f