From marko.prykladna at gmail.com  Wed May  2 10:57:57 2018
From: marko.prykladna at gmail.com (Marko Bekhta)
Date: Wed, 2 May 2018 16:57:57 +0200
Subject: [weld-dev] @WithAnnotations filtering not picking up annotations
 from implemented interfaces
Message-ID: <CACYzyetHW5TK=GYFAc0uiJBSCKprvVQDwRw+_Xa5tZnWosid0g@mail.gmail.com>

Hi all,

In Hibernate Validator CDI extension we are using @WithAnnotations to filter
beans that potentially need to be validated (for actual usage see [1]):

public <T> void processAnnotatedType(@Observes @WithAnnotations({
Constraint.class,
Valid.class,
ValidateOnExecution.class
}) ProcessAnnotatedType<T> processAnnotatedTypeEvent) {
// doing something ...
}

The problem that we've stumbled upon is that it looks like this filtering
does
not take into account the information from implemented interfaces. For
example
let's assume we have an interface:

@ValidateOnExecution(type = ExecutableType.ALL)
public interface ShipmentService {
public void findShipment(@NotNull String id);
}

which is implemented by ShipmentServiceImpl:

public class ShipmentServiceImpl implements ShipmentService {

@Override
public void findShipment(String id) {
}
}

Our expectation would be that as interface is marked with one of the
annotations
listed among values of @WithAnnotations filter, the corresponding bean
(ShipmentServiceImpl) would be pushed to processAnnotatedType(..) method.
But it
is not. As a result we don't create a validation proxy and corresponding
service
bean never performs any validation operations.  In case when any of the
filtered
annotations is added to the impl bean things start to work (impl bean is
processed).

The above case shows placement of annotation on a type level, but similar
behavior is observed in cases when annotation is on a method level.

As forcing presence of one of the annotations from the filter list on a impl
beans is not really an option, an alternative could be to drop the
@WithAnnotations filtering completely. Which is also not that great, as
dropping the filtering would mean that:

- Validation extension would need to process all possible beans that are
available
- Such processing requires calls to Hibernate Validatior which must create
the metadata
for each bean hierarchy and store it, even if nobody actually needs to
validate those
beans.
- This would lead to much greater memory consumption as well as longer
bootstrap
time. Which is not good.

Hence we would like to ask if there is any particular reasons why
@WithAnnotations
filter does not consider looking at super classes and implemented
interfaces to check
for annotations listed in @WithAnnotations?

Have a nice day,
Marko

[1]
https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main/java/org/hibernate/validator/cdi/ValidationExtension.java#L222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180502/d2d97348/attachment.html 

From mkouba at redhat.com  Wed May  2 11:25:22 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 2 May 2018 17:25:22 +0200
Subject: [weld-dev] @WithAnnotations filtering not picking up
 annotations from implemented interfaces
In-Reply-To: <CACYzyetHW5TK=GYFAc0uiJBSCKprvVQDwRw+_Xa5tZnWosid0g@mail.gmail.com>
References: <CACYzyetHW5TK=GYFAc0uiJBSCKprvVQDwRw+_Xa5tZnWosid0g@mail.gmail.com>
Message-ID: <9d084213-5cf4-b734-7444-094783b6c0ea@redhat.com>

Hi Marko,

comments inline...

Dne 2.5.2018 v 16:57 Marko Bekhta napsal(a):
> Hi all,
> 
> In Hibernate Validator CDI extension we are using @WithAnnotations to filter
> beans that potentially need to be validated (for actual usage see [1]):
> 
> public <T> void processAnnotatedType(@Observes @WithAnnotations({
> Constraint.class,
> Valid.class,
> ValidateOnExecution.class
> }) ProcessAnnotatedType<T> processAnnotatedTypeEvent) {
> // doing something ...
> }
> 
> The problem that we've stumbled upon is that it looks like this 
> filtering does
> not take into account the information from implemented interfaces. For 
> example
> let's assume we have an interface:
> 
> @ValidateOnExecution(type = ExecutableType.ALL)
> public interface ShipmentService {
> public void findShipment(@NotNull String id);
> }
> 
> which is implemented by ShipmentServiceImpl:
> 
> public class ShipmentServiceImpl implements ShipmentService {
> 
> @Override
> public void findShipment(String id) {
> }
> }
> 
> Our expectation would be that as interface is marked with one of the 
> annotations
> listed among values of @WithAnnotations filter, the corresponding bean
> (ShipmentServiceImpl) would be pushed to processAnnotatedType(..) 
> method. But it
> is not. As a result we don't create a validation proxy and corresponding 
> service
> bean never performs any validation operations.? In case when any of the 
> filtered
> annotations is added to the impl bean things start to work (impl bean is 
> processed).
> 
> The above case shows placement of annotation on a type level, but similar
> behavior is observed in cases when annotation is on a method level.
> 
> As forcing presence of one of the annotations from the filter list on a impl
> beans is not really an option, an alternative could be to drop the
> @WithAnnotations filtering completely. Which is also not that great, as
> dropping the filtering would mean that:
> 
> - Validation extension would need to process all possible beans that are 
> available
> - Such processing requires calls to Hibernate Validatior which must 
> create the metadata
> for each bean hierarchy and store it, even if nobody actually needs to 
> validate those
> beans.
> - This would lead to much greater memory consumption as well as longer 
> bootstrap
> time. Which is not good.
> 
> Hence we would like to ask if there is any particular reasons why 
> @WithAnnotations

Well, the reason is that the spec requires this:

"If the annotation is applied, the container must only deliver 
ProcessAnnotatedType events for types which contain at least one of the 
annotations specified. The annotation can appear on the annotated type, 
or on any member, or any parameter of any member of the annotated type, 
as defined in Alternative metadata sources."

See also 
http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#process_annotated_type

Annotations should be inherited (and PAT fired) if @Inherited 
meta-annotation is used. But I'm not quite sure this works. Also note 
that annotations are never inherited from interfaces (see also 
java.lang.annotation.Inherited javadoc)!

> filter does not consider looking at super classes and implemented 
> interfaces to check
> for annotations listed in @WithAnnotations?

> 
> Have a nice day,
> Marko
> 
> [1] 
> https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main/java/org/hibernate/validator/cdi/ValidationExtension.java#L222
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From marko.prykladna at gmail.com  Wed May  2 11:57:51 2018
From: marko.prykladna at gmail.com (Marko Bekhta)
Date: Wed, 2 May 2018 17:57:51 +0200
Subject: [weld-dev] @WithAnnotations filtering not picking up
 annotations from implemented interfaces
In-Reply-To: <9d084213-5cf4-b734-7444-094783b6c0ea@redhat.com>
References: <CACYzyetHW5TK=GYFAc0uiJBSCKprvVQDwRw+_Xa5tZnWosid0g@mail.gmail.com>
	<9d084213-5cf4-b734-7444-094783b6c0ea@redhat.com>
Message-ID: <CACYzyetvELkn0oMRH3LDkb=LkkR4NNpMHjsc5AzM0qqNZEdk6w@mail.gmail.com>

Ahh, I see, it's a part of the spec. So basically if we wanted to do it the
other
way there's no other option then remove the @WithAnnotations, receive all
PATs and do the filtering on our side, right?

And also thanks for a quick response!

Have a nice day,
Marko


2018-05-02 17:25 GMT+02:00 Martin Kouba <mkouba at redhat.com>:

> Hi Marko,
>
> comments inline...
>
> Dne 2.5.2018 v 16:57 Marko Bekhta napsal(a):
>
> Hi all,
>>
>> In Hibernate Validator CDI extension we are using @WithAnnotations to
>> filter
>> beans that potentially need to be validated (for actual usage see [1]):
>>
>> public <T> void processAnnotatedType(@Observes @WithAnnotations({
>> Constraint.class,
>> Valid.class,
>> ValidateOnExecution.class
>> }) ProcessAnnotatedType<T> processAnnotatedTypeEvent) {
>> // doing something ...
>> }
>>
>> The problem that we've stumbled upon is that it looks like this filtering
>> does
>> not take into account the information from implemented interfaces. For
>> example
>> let's assume we have an interface:
>>
>> @ValidateOnExecution(type = ExecutableType.ALL)
>> public interface ShipmentService {
>> public void findShipment(@NotNull String id);
>> }
>>
>> which is implemented by ShipmentServiceImpl:
>>
>> public class ShipmentServiceImpl implements ShipmentService {
>>
>> @Override
>> public void findShipment(String id) {
>> }
>> }
>>
>> Our expectation would be that as interface is marked with one of the
>> annotations
>> listed among values of @WithAnnotations filter, the corresponding bean
>> (ShipmentServiceImpl) would be pushed to processAnnotatedType(..) method.
>> But it
>> is not. As a result we don't create a validation proxy and corresponding
>> service
>> bean never performs any validation operations.  In case when any of the
>> filtered
>> annotations is added to the impl bean things start to work (impl bean is
>> processed).
>>
>> The above case shows placement of annotation on a type level, but similar
>> behavior is observed in cases when annotation is on a method level.
>>
>> As forcing presence of one of the annotations from the filter list on a
>> impl
>> beans is not really an option, an alternative could be to drop the
>> @WithAnnotations filtering completely. Which is also not that great, as
>> dropping the filtering would mean that:
>>
>> - Validation extension would need to process all possible beans that are
>> available
>> - Such processing requires calls to Hibernate Validatior which must
>> create the metadata
>> for each bean hierarchy and store it, even if nobody actually needs to
>> validate those
>> beans.
>> - This would lead to much greater memory consumption as well as longer
>> bootstrap
>> time. Which is not good.
>>
>> Hence we would like to ask if there is any particular reasons why
>> @WithAnnotations
>>
>
> Well, the reason is that the spec requires this:
>
> "If the annotation is applied, the container must only deliver
> ProcessAnnotatedType events for types which contain at least one of the
> annotations specified. The annotation can appear on the annotated type, or
> on any member, or any parameter of any member of the annotated type, as
> defined in Alternative metadata sources."
>
> See also http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#process_
> annotated_type
>
> Annotations should be inherited (and PAT fired) if @Inherited
> meta-annotation is used. But I'm not quite sure this works. Also note that
> annotations are never inherited from interfaces (see also
> java.lang.annotation.Inherited javadoc)!
>
> filter does not consider looking at super classes and implemented
>> interfaces to check
>> for annotations listed in @WithAnnotations?
>>
>
>
>> Have a nice day,
>> Marko
>>
>> [1] https://github.com/hibernate/hibernate-validator/blob/master
>> /cdi/src/main/java/org/hibernate/validator/cdi/ValidationExt
>> ension.java#L222
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180502/4d75d1c6/attachment.html 

From mkouba at redhat.com  Wed May  2 12:56:03 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 2 May 2018 18:56:03 +0200
Subject: [weld-dev] @WithAnnotations filtering not picking up
 annotations from implemented interfaces
In-Reply-To: <CACYzyetvELkn0oMRH3LDkb=LkkR4NNpMHjsc5AzM0qqNZEdk6w@mail.gmail.com>
References: <CACYzyetHW5TK=GYFAc0uiJBSCKprvVQDwRw+_Xa5tZnWosid0g@mail.gmail.com>
	<9d084213-5cf4-b734-7444-094783b6c0ea@redhat.com>
	<CACYzyetvELkn0oMRH3LDkb=LkkR4NNpMHjsc5AzM0qqNZEdk6w@mail.gmail.com>
Message-ID: <d51cf0ec-caeb-8b98-db5a-7bf75bc0348c@redhat.com>

Dne 2.5.2018 v 17:57 Marko Bekhta napsal(a):
> Ahh, I see, it's a part of the spec. So basically if we wanted to do it 
> the other
> way there's no other option then remove the @WithAnnotations, receive all
> PATs and do the filtering on our side, right?

Yes. In theory, we could implement something weld-specific but then your 
extension would not be portable.

> 
> And also thanks for a quick response!
> 
> Have a nice day,
> Marko
> 
> 
> 2018-05-02 17:25 GMT+02:00 Martin Kouba <mkouba at redhat.com 
> <mailto:mkouba at redhat.com>>:
>
>     Hi Marko,
> 
>     comments inline...
> 
>     Dne 2.5.2018 v 16:57 Marko Bekhta napsal(a):
> 
>         Hi all,
> 
>         In Hibernate Validator CDI extension we are using
>         @WithAnnotations to filter
>         beans that potentially need to be validated (for actual usage
>         see [1]):
> 
>         public <T> void processAnnotatedType(@Observes @WithAnnotations({
>         Constraint.class,
>         Valid.class,
>         ValidateOnExecution.class
>         }) ProcessAnnotatedType<T> processAnnotatedTypeEvent) {
>         // doing something ...
>         }
> 
>         The problem that we've stumbled upon is that it looks like this
>         filtering does
>         not take into account the information from implemented
>         interfaces. For example
>         let's assume we have an interface:
> 
>         @ValidateOnExecution(type = ExecutableType.ALL)
>         public interface ShipmentService {
>         public void findShipment(@NotNull String id);
>         }
> 
>         which is implemented by ShipmentServiceImpl:
> 
>         public class ShipmentServiceImpl implements ShipmentService {
> 
>         @Override
>         public void findShipment(String id) {
>         }
>         }
> 
>         Our expectation would be that as interface is marked with one of
>         the annotations
>         listed among values of @WithAnnotations filter, the
>         corresponding bean
>         (ShipmentServiceImpl) would be pushed to
>         processAnnotatedType(..) method. But it
>         is not. As a result we don't create a validation proxy and
>         corresponding service
>         bean never performs any validation operations.? In case when any
>         of the filtered
>         annotations is added to the impl bean things start to work (impl
>         bean is processed).
> 
>         The above case shows placement of annotation on a type level,
>         but similar
>         behavior is observed in cases when annotation is on a method level.
> 
>         As forcing presence of one of the annotations from the filter
>         list on a impl
>         beans is not really an option, an alternative could be to drop the
>         @WithAnnotations filtering completely. Which is also not that
>         great, as
>         dropping the filtering would mean that:
> 
>         - Validation extension would need to process all possible beans
>         that are available
>         - Such processing requires calls to Hibernate Validatior which
>         must create the metadata
>         for each bean hierarchy and store it, even if nobody actually
>         needs to validate those
>         beans.
>         - This would lead to much greater memory consumption as well as
>         longer bootstrap
>         time. Which is not good.
> 
>         Hence we would like to ask if there is any particular reasons
>         why @WithAnnotations
> 
> 
>     Well, the reason is that the spec requires this:
> 
>     "If the annotation is applied, the container must only deliver
>     ProcessAnnotatedType events for types which contain at least one of
>     the annotations specified. The annotation can appear on the
>     annotated type, or on any member, or any parameter of any member of
>     the annotated type, as defined in Alternative metadata sources."
> 
>     See also
>     http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#process_annotated_type
>     <http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#process_annotated_type>
> 
>     Annotations should be inherited (and PAT fired) if @Inherited
>     meta-annotation is used. But I'm not quite sure this works. Also
>     note that annotations are never inherited from interfaces (see also
>     java.lang.annotation.Inherited javadoc)!
> 
>         filter does not consider looking at super classes and
>         implemented interfaces to check
>         for annotations listed in @WithAnnotations?
> 
> 
> 
>         Have a nice day,
>         Marko
> 
>         [1]
>         https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main/java/org/hibernate/validator/cdi/ValidationExtension.java#L222
>         <https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main/java/org/hibernate/validator/cdi/ValidationExtension.java#L222>
> 
> 
>         _______________________________________________
>         weld-dev mailing list
>         weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/weld-dev
>         <https://lists.jboss.org/mailman/listinfo/weld-dev>
> 
> 
>     -- 
>     Martin Kouba
>     Senior Software Engineer
>     Red Hat, Czech Republic
> 
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From ooo_saturn7 at mail.ru  Tue May  8 03:51:38 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Tue, 08 May 2018 10:51:38 +0300
Subject: [weld-dev] =?utf-8?q?Weld_and_JPMS?=
Message-ID: <1525765898.907587911@f465.i.mail.ru>

Hi all

Half a year has passed since Java 9 release. Can anyone say if there are any documentation,
solutions etc how to work with JPMS in Weld?


-- 
Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180508/eaf43a05/attachment.html 

From manovotn at redhat.com  Wed May  9 07:54:34 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Wed, 9 May 2018 07:54:34 -0400 (EDT)
Subject: [weld-dev] Weld and JPMS
In-Reply-To: <1525765898.907587911@f465.i.mail.ru>
References: <1525765898.907587911@f465.i.mail.ru>
Message-ID: <919776960.28367053.1525866874196.JavaMail.zimbra@redhat.com>

Hi Alex,

in short, there is no official documentation on that because Weld runs in "classpath mode".

JDK 9  and 10 are short-termed releases and will have no special support.
JDK 11 is something we should be looking at and we are doing that (lately we added support to avoid illegal access there for instance).

When it comes to JPMS itself, the question is, in what environment are you running?
If it's EE (e.g. in a server like WildFly), then all magic needs to be worked on server side, pretty much. 
I know WildFly already has some of it, but I am pretty sure at this point most servers won't fully support JPMS.

If in SE, then Weld itself is not defined as JPMS module and hence will end up in an unnamed module (Weld has no module-info).
There is no way we can avoid deep reflection on your classes (for instance to be able to intercept non-public methods), therefore you need to make sure your classes
allow us to do that (or rather to unnamed module where Weld resides ATM). Having done that, it should work.

Matej


----- Original Message -----
> From: "Alex Sviridov" <ooo_saturn7 at mail.ru>
> To: "weld-dev" <weld-dev at lists.jboss.org>
> Sent: Tuesday, May 8, 2018 9:51:38 AM
> Subject: [weld-dev] Weld and JPMS
> 
> Hi all
> 
> Half a year has passed since Java 9 release. Can anyone say if there are any
> documentation,
> solutions etc how to work with JPMS in Weld?
> 
> 
> --
> Alex Sviridov
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

From ooo_saturn7 at mail.ru  Wed May  9 08:09:56 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Wed, 09 May 2018 15:09:56 +0300
Subject: [weld-dev] =?utf-8?q?Weld_and_JPMS?=
In-Reply-To: <919776960.28367053.1525866874196.JavaMail.zimbra@redhat.com>
References: <1525765898.907587911@f465.i.mail.ru>
	<919776960.28367053.1525866874196.JavaMail.zimbra@redhat.com>
Message-ID: <1525867796.985036188@f482.i.mail.ru>

Hi Matej,

Thank you for such a detailed answer. If I understand you right Weld in not modular according to JPMS specs.
If so, then are there any plans (opened issues) to make it modular? 

Besides, one question is very interesting for me - will Weld create separate container for every JPMS module 
or Weld will create one container for all JPMS modules?

Best regards, Alex

>?????,  9 ??? 2018, 14:54 +03:00 ?? Matej Novotny <manovotn at redhat.com>:
>
>Hi Alex,
>
>in short, there is no official documentation on that because Weld runs in "classpath mode".
>
>JDK 9  and 10 are short-termed releases and will have no special support.
>JDK 11 is something we should be looking at and we are doing that (lately we added support to avoid illegal access there for instance).
>
>When it comes to JPMS itself, the question is, in what environment are you running?
>If it's EE (e.g. in a server like WildFly), then all magic needs to be worked on server side, pretty much. 
>I know WildFly already has some of it, but I am pretty sure at this point most servers won't fully support JPMS.
>
>If in SE, then Weld itself is not defined as JPMS module and hence will end up in an unnamed module (Weld has no module-info).
>There is no way we can avoid deep reflection on your classes (for instance to be able to intercept non-public methods), therefore you need to make sure your classes
>allow us to do that (or rather to unnamed module where Weld resides ATM). Having done that, it should work.
>
>Matej
>
>
>----- Original Message -----
>> From: "Alex Sviridov" < ooo_saturn7 at mail.ru >
>> To: "weld-dev" < weld-dev at lists.jboss.org >
>> Sent: Tuesday, May 8, 2018 9:51:38 AM
>> Subject: [weld-dev] Weld and JPMS
>> 
>> Hi all
>> 
>> Half a year has passed since Java 9 release. Can anyone say if there are any
>> documentation,
>> solutions etc how to work with JPMS in Weld?
>> 
>> 
>> --
>> Alex Sviridov
>> 
>> _______________________________________________
>> weld-dev mailing list
>>  weld-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/weld-dev


-- 
Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180509/5b7abf27/attachment.html 

From manovotn at redhat.com  Wed May  9 08:38:28 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Wed, 9 May 2018 08:38:28 -0400 (EDT)
Subject: [weld-dev] Weld and JPMS
In-Reply-To: <1525867796.985036188@f482.i.mail.ru>
References: <1525765898.907587911@f465.i.mail.ru>
	<919776960.28367053.1525866874196.JavaMail.zimbra@redhat.com>
	<1525867796.985036188@f482.i.mail.ru>
Message-ID: <2124057965.28384996.1525869508794.JavaMail.zimbra@redhat.com>

Comments inline

Matej

----- Original Message -----
> From: "Alex Sviridov" <ooo_saturn7 at mail.ru>
> To: "Matej Novotny" <manovotn at redhat.com>, "weld-dev" <weld-dev at lists.jboss.org>
> Sent: Wednesday, May 9, 2018 2:09:56 PM
> Subject: Re[2]: [weld-dev] Weld and JPMS
> 
> Hi Matej,
> 
> Thank you for such a detailed answer. If I understand you right Weld in not
> modular according to JPMS specs.
> If so, then are there any plans (opened issues) to make it modular?

There are no opened issues at the moment, feel free to create one, however I cannot guarantee you any time-bound implementation.
Weld is (as as a reference implementation of CDI) mainly looking at EE and there we need to see how EE-world deals with the burden that is called JPMS.
When it comes to SE, the problem is we will need to come up with something that, in the same time, won't break EE behaviour (SE is re-using same core as is in EE and so forth).

> 
> Besides, one question is very interesting for me - will Weld create separate
> container for every JPMS module
> or Weld will create one container for all JPMS modules?

Not sure I understand you correctly, but I see no benefit in running parallel Weld containers?
Weld will have to behave as it did until now (backward compatibility), which effectively means one container for all JPMS modules in that deployment.

> 
> Best regards, Alex
> 
> >?????,  9 ??? 2018, 14:54 +03:00 ?? Matej Novotny <manovotn at redhat.com>:
> >
> >Hi Alex,
> >
> >in short, there is no official documentation on that because Weld runs in
> >"classpath mode".
> >
> >JDK 9  and 10 are short-termed releases and will have no special support.
> >JDK 11 is something we should be looking at and we are doing that (lately we
> >added support to avoid illegal access there for instance).
> >
> >When it comes to JPMS itself, the question is, in what environment are you
> >running?
> >If it's EE (e.g. in a server like WildFly), then all magic needs to be
> >worked on server side, pretty much.
> >I know WildFly already has some of it, but I am pretty sure at this point
> >most servers won't fully support JPMS.
> >
> >If in SE, then Weld itself is not defined as JPMS module and hence will end
> >up in an unnamed module (Weld has no module-info).
> >There is no way we can avoid deep reflection on your classes (for instance
> >to be able to intercept non-public methods), therefore you need to make
> >sure your classes
> >allow us to do that (or rather to unnamed module where Weld resides ATM).
> >Having done that, it should work.
> >
> >Matej
> >
> >
> >----- Original Message -----
> >> From: "Alex Sviridov" < ooo_saturn7 at mail.ru >
> >> To: "weld-dev" < weld-dev at lists.jboss.org >
> >> Sent: Tuesday, May 8, 2018 9:51:38 AM
> >> Subject: [weld-dev] Weld and JPMS
> >> 
> >> Hi all
> >> 
> >> Half a year has passed since Java 9 release. Can anyone say if there are
> >> any
> >> documentation,
> >> solutions etc how to work with JPMS in Weld?
> >> 
> >> 
> >> --
> >> Alex Sviridov
> >> 
> >> _______________________________________________
> >> weld-dev mailing list
> >>  weld-dev at lists.jboss.org
> >>  https://lists.jboss.org/mailman/listinfo/weld-dev
> 
> 
> --
> Alex Sviridov
> 


From ooo_saturn7 at mail.ru  Wed May  9 08:43:54 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Wed, 09 May 2018 15:43:54 +0300
Subject: [weld-dev] =?utf-8?q?Weld_and_JPMS?=
In-Reply-To: <2124057965.28384996.1525869508794.JavaMail.zimbra@redhat.com>
References: <1525765898.907587911@f465.i.mail.ru>
	<1525867796.985036188@f482.i.mail.ru>
	<2124057965.28384996.1525869508794.JavaMail.zimbra@redhat.com>
Message-ID: <1525869834.151490053@f168.i.mail.ru>

Thank you again. I opened an issue  https://issues.jboss.org/browse/WELD-2493 ?


>?????,  9 ??? 2018, 15:38 +03:00 ?? Matej Novotny <manovotn at redhat.com>:
>
>Comments inline
>
>Matej
>
>----- Original Message -----
>> From: "Alex Sviridov" < ooo_saturn7 at mail.ru >
>> To: "Matej Novotny" < manovotn at redhat.com >, "weld-dev" < weld-dev at lists.jboss.org >
>> Sent: Wednesday, May 9, 2018 2:09:56 PM
>> Subject: Re[2]: [weld-dev] Weld and JPMS
>> 
>> Hi Matej,
>> 
>> Thank you for such a detailed answer. If I understand you right Weld in not
>> modular according to JPMS specs.
>> If so, then are there any plans (opened issues) to make it modular?
>
>There are no opened issues at the moment, feel free to create one, however I cannot guarantee you any time-bound implementation.
>Weld is (as as a reference implementation of CDI) mainly looking at EE and there we need to see how EE-world deals with the burden that is called JPMS.
>When it comes to SE, the problem is we will need to come up with something that, in the same time, won't break EE behaviour (SE is re-using same core as is in EE and so forth).
>
>> 
>> Besides, one question is very interesting for me - will Weld create separate
>> container for every JPMS module
>> or Weld will create one container for all JPMS modules?
>
>Not sure I understand you correctly, but I see no benefit in running parallel Weld containers?
>Weld will have to behave as it did until now (backward compatibility), which effectively means one container for all JPMS modules in that deployment.
>
>> 
>> Best regards, Alex
>> 
>> >?????,  9 ??? 2018, 14:54 +03:00 ?? Matej Novotny < manovotn at redhat.com >:
>> >
>> >Hi Alex,
>> >
>> >in short, there is no official documentation on that because Weld runs in
>> >"classpath mode".
>> >
>> >JDK 9  and 10 are short-termed releases and will have no special support.
>> >JDK 11 is something we should be looking at and we are doing that (lately we
>> >added support to avoid illegal access there for instance).
>> >
>> >When it comes to JPMS itself, the question is, in what environment are you
>> >running?
>> >If it's EE (e.g. in a server like WildFly), then all magic needs to be
>> >worked on server side, pretty much.
>> >I know WildFly already has some of it, but I am pretty sure at this point
>> >most servers won't fully support JPMS.
>> >
>> >If in SE, then Weld itself is not defined as JPMS module and hence will end
>> >up in an unnamed module (Weld has no module-info).
>> >There is no way we can avoid deep reflection on your classes (for instance
>> >to be able to intercept non-public methods), therefore you need to make
>> >sure your classes
>> >allow us to do that (or rather to unnamed module where Weld resides ATM).
>> >Having done that, it should work.
>> >
>> >Matej
>> >
>> >
>> >----- Original Message -----
>> >> From: "Alex Sviridov" <  ooo_saturn7 at mail.ru >
>> >> To: "weld-dev" <  weld-dev at lists.jboss.org >
>> >> Sent: Tuesday, May 8, 2018 9:51:38 AM
>> >> Subject: [weld-dev] Weld and JPMS
>> >> 
>> >> Hi all
>> >> 
>> >> Half a year has passed since Java 9 release. Can anyone say if there are
>> >> any
>> >> documentation,
>> >> solutions etc how to work with JPMS in Weld?
>> >> 
>> >> 
>> >> --
>> >> Alex Sviridov
>> >> 
>> >> _______________________________________________
>> >> weld-dev mailing list
>> >>  weld-dev at lists.jboss.org
>> >>  https://lists.jboss.org/mailman/listinfo/weld-dev
>> 
>> 
>> --
>> Alex Sviridov
>> 


-- 
Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180509/393e7181/attachment-0001.html 

From ooo_saturn7 at mail.ru  Tue May 15 09:24:35 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Tue, 15 May 2018 16:24:35 +0300
Subject: [weld-dev] =?utf-8?q?Weld_and_JPMS?=
In-Reply-To: <919776960.28367053.1525866874196.JavaMail.zimbra@redhat.com>
References: <1525765898.907587911@f465.i.mail.ru>
	<919776960.28367053.1525866874196.JavaMail.zimbra@redhat.com>
Message-ID: <1526390675.428872947@f161.i.mail.ru>


Hi Matej

I reread your answer, and have another question - can Weld run in module path as auto module?

>?????,  9 ??? 2018, 14:54 +03:00 ?? Matej Novotny <manovotn at redhat.com>:
>
>Hi Alex,
>
>in short, there is no official documentation on that because Weld runs in "classpath mode".
>
>JDK 9  and 10 are short-termed releases and will have no special support.
>JDK 11 is something we should be looking at and we are doing that (lately we added support to avoid illegal access there for instance).
>
>When it comes to JPMS itself, the question is, in what environment are you running?
>If it's EE (e.g. in a server like WildFly), then all magic needs to be worked on server side, pretty much. 
>I know WildFly already has some of it, but I am pretty sure at this point most servers won't fully support JPMS.
>
>If in SE, then Weld itself is not defined as JPMS module and hence will end up in an unnamed module (Weld has no module-info).
>There is no way we can avoid deep reflection on your classes (for instance to be able to intercept non-public methods), therefore you need to make sure your classes
>allow us to do that (or rather to unnamed module where Weld resides ATM). Having done that, it should work.
>
>Matej
>
>
>----- Original Message -----
>> From: "Alex Sviridov" < ooo_saturn7 at mail.ru >
>> To: "weld-dev" < weld-dev at lists.jboss.org >
>> Sent: Tuesday, May 8, 2018 9:51:38 AM
>> Subject: [weld-dev] Weld and JPMS
>> 
>> Hi all
>> 
>> Half a year has passed since Java 9 release. Can anyone say if there are any
>> documentation,
>> solutions etc how to work with JPMS in Weld?
>> 
>> 
>> --
>> Alex Sviridov
>> 
>> _______________________________________________
>> weld-dev mailing list
>>  weld-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/weld-dev


-- 
Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180515/d6029a2d/attachment.html 

From manovotn at redhat.com  Wed May 16 02:42:31 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Wed, 16 May 2018 02:42:31 -0400 (EDT)
Subject: [weld-dev] Weld and JPMS
In-Reply-To: <1526390675.428872947@f161.i.mail.ru>
References: <1525765898.907587911@f465.i.mail.ru>
	<919776960.28367053.1525866874196.JavaMail.zimbra@redhat.com>
	<1526390675.428872947@f161.i.mail.ru>
Message-ID: <1092723682.30154335.1526452951649.JavaMail.zimbra@redhat.com>

Hi Alex

technically speaking it should - this is implied by how jigsaw works.
However, it will be very difficult to set up and use due to auto-module naming.
You will need your crystal ball to guess what are the module names to which you need to allow deep reflection.
And likewise what auto-modules do you need to depend on.

I haven't tried this though, so take what I say with a pinch of salt.
If you do some testing, I'll be glad to hear the results as well.

Matej

----- Original Message -----
> From: "Alex Sviridov" <ooo_saturn7 at mail.ru>
> To: "Matej Novotny" <manovotn at redhat.com>, "weld-dev" <weld-dev at lists.jboss.org>
> Sent: Tuesday, May 15, 2018 3:24:35 PM
> Subject: Re[2]: [weld-dev] Weld and JPMS
> 
> 
> Hi Matej
> 
> I reread your answer, and have another question - can Weld run in module path
> as auto module?
> 
> >?????,  9 ??? 2018, 14:54 +03:00 ?? Matej Novotny <manovotn at redhat.com>:
> >
> >Hi Alex,
> >
> >in short, there is no official documentation on that because Weld runs in
> >"classpath mode".
> >
> >JDK 9  and 10 are short-termed releases and will have no special support.
> >JDK 11 is something we should be looking at and we are doing that (lately we
> >added support to avoid illegal access there for instance).
> >
> >When it comes to JPMS itself, the question is, in what environment are you
> >running?
> >If it's EE (e.g. in a server like WildFly), then all magic needs to be
> >worked on server side, pretty much.
> >I know WildFly already has some of it, but I am pretty sure at this point
> >most servers won't fully support JPMS.
> >
> >If in SE, then Weld itself is not defined as JPMS module and hence will end
> >up in an unnamed module (Weld has no module-info).
> >There is no way we can avoid deep reflection on your classes (for instance
> >to be able to intercept non-public methods), therefore you need to make
> >sure your classes
> >allow us to do that (or rather to unnamed module where Weld resides ATM).
> >Having done that, it should work.
> >
> >Matej
> >
> >
> >----- Original Message -----
> >> From: "Alex Sviridov" < ooo_saturn7 at mail.ru >
> >> To: "weld-dev" < weld-dev at lists.jboss.org >
> >> Sent: Tuesday, May 8, 2018 9:51:38 AM
> >> Subject: [weld-dev] Weld and JPMS
> >> 
> >> Hi all
> >> 
> >> Half a year has passed since Java 9 release. Can anyone say if there are
> >> any
> >> documentation,
> >> solutions etc how to work with JPMS in Weld?
> >> 
> >> 
> >> --
> >> Alex Sviridov
> >> 
> >> _______________________________________________
> >> weld-dev mailing list
> >>  weld-dev at lists.jboss.org
> >>  https://lists.jboss.org/mailman/listinfo/weld-dev
> 
> 
> --
> Alex Sviridov
> 


From ooo_saturn7 at mail.ru  Wed May 16 07:51:20 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Wed, 16 May 2018 14:51:20 +0300
Subject: [weld-dev] =?utf-8?q?Staring_weld_container_for_SE_environment_ma?=
 =?utf-8?q?kes_me_load_java_ee_classes=2E?=
Message-ID: <1526471479.117220955@f423.i.mail.ru>

Hi all

I am trying to start weld container (2.3.5) as auto module in JPMS. This is my code

??????? Deployment deployment = new Deployment() {
??????????? @Override
??????????? public Collection<BeanDeploymentArchive> getBeanDeploymentArchives() {
??????????????? List<BeanDeploymentArchive> list = new ArrayList<>();
??????????????? list.add(archive);
??????????????? return list;
??????????? }

??????????? @Override
??????????? public BeanDeploymentArchive loadBeanDeploymentArchive(Class<?> beanClass) {
??????????????? throw new UnsupportedOperationException("Not supported yet.");
??????????? }

??????????? @Override
??????????? public ServiceRegistry getServices() {
??????????????? SimpleServiceRegistry simpleServiceRegistry = new SimpleServiceRegistry();
??????????????? simpleServiceRegistry.add(ResourceLoader.class, new ResourceLoaderImpl());
??????????????? return simpleServiceRegistry;
??????????? }

??????????? @Override
??????????? public Iterable getExtensions() {
??????????????? return new ArrayList<>();
??????????? }
??????? };

??????? bootstrap.startContainer(Environments.SE, deployment);

The problem is that in BeanDeployment constructor all services are loaded here  https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/bootstrap/BeanDeployment.java#L117 and if I in my resource loader service return instead of all java-ee classes null, I get null pointer exception, for example here  https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/ejb/EJBApiAbstraction.java#L44

I can't understand why all these classes are requested from me, as I am in SE. Or I am doing something wrong. Could anyone help me?

-- 
Best regards, Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180516/449ef1e6/attachment.html 

From manovotn at redhat.com  Wed May 16 09:47:34 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Wed, 16 May 2018 09:47:34 -0400 (EDT)
Subject: [weld-dev] Staring weld container for SE environment makes me
 load java ee classes.
In-Reply-To: <1526471479.117220955@f423.i.mail.ru>
References: <1526471479.117220955@f423.i.mail.ru>
Message-ID: <1557659196.30311132.1526478454502.JavaMail.zimbra@redhat.com>

Weld 2.x is NOT to be executed with Java 9+.
Use Weld 3, please. Best use latest release of course (3.0.4.Final).

If you can share the test project on GH, that would be neat as well.
Then we could see how you use weld as auto module (as well as many other configurations) and go from there.

As for starting SE container, you shouldn't manually call `bootstrap.startContainer(Environments.SE, deployment);`
Please see the docs on how to bootstrap Weld in SE, you shouldn't need to deal with any of the methods you listed below.
Here is a doc link - http://docs.jboss.org/weld/reference/latest-master/en-US/html_single/#_bootstrapping_cdi_se

Regards
Matej

----- Original Message -----
> From: "Alex Sviridov" <ooo_saturn7 at mail.ru>
> To: "weld-dev" <weld-dev at lists.jboss.org>
> Sent: Wednesday, May 16, 2018 1:51:20 PM
> Subject: [weld-dev] Staring weld container for SE environment makes me load java ee classes.
> 
> Hi all
> 
> I am trying to start weld container (2.3.5) as auto module in JPMS. This is
> my code
> 
> Deployment deployment = new Deployment() {
> @Override
> public Collection<BeanDeploymentArchive> getBeanDeploymentArchives() {
> List<BeanDeploymentArchive> list = new ArrayList<>();
> list.add(archive);
> return list;
> }
> 
> @Override
> public BeanDeploymentArchive loadBeanDeploymentArchive(Class<?> beanClass) {
> throw new UnsupportedOperationException("Not supported yet.");
> }
> 
> @Override
> public ServiceRegistry getServices() {
> SimpleServiceRegistry simpleServiceRegistry = new SimpleServiceRegistry();
> simpleServiceRegistry.add(ResourceLoader.class, new ResourceLoaderImpl());
> return simpleServiceRegistry;
> }
> 
> @Override
> public Iterable getExtensions() {
> return new ArrayList<>();
> }
> };
> 
> bootstrap.startContainer(Environments.SE, deployment);
> 
> The problem is that in BeanDeployment constructor all services are loaded
> here
> https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/bootstrap/BeanDeployment.java#L117
> and if I in my resource loader service return instead of all java-ee classes
> null, I get null pointer exception, for example here
> https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/ejb/EJBApiAbstraction.java#L44
> 
> I can't understand why all these classes are requested from me, as I am in
> SE. Or I am doing something wrong. Could anyone help me?
> 
> --
> Best regards, Alex Sviridov
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

From ooo_saturn7 at mail.ru  Wed May 16 14:02:14 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Wed, 16 May 2018 21:02:14 +0300
Subject: [weld-dev]
 =?utf-8?q?Staring_weld_container_for_SE_environment_ma?=
 =?utf-8?q?kes_me_load_java_ee_classes=2E?=
In-Reply-To: <1557659196.30311132.1526478454502.JavaMail.zimbra@redhat.com>
References: <1526471479.117220955@f423.i.mail.ru>
	<1557659196.30311132.1526478454502.JavaMail.zimbra@redhat.com>
Message-ID: <1526493734.103531037@f310.i.mail.ru>


Hi Matej

I followed your answer and run Weld (SE) as auto module in my JPMS layer. In this layer I have an arhive with beans.xml
This is my code:
?????? Weld weld = new Weld();
??????? WeldContainer container = weld.initialize();

This is what I get:

INFO: WELD-000900: 3.0.4 (Final)
May 16, 2018 7:00:39 PM org.jboss.weld.environment.deployment.discovery.ReflectionDiscoveryStrategy processAnnotatedDiscovery
INFO: WELD-ENV-000014: Falling back to Java Reflection for bean-discovery-mode="annotated" discovery. Add org.jboss:jandex to the classpath to speed-up startup.
2018-05-16 19:00:39:187 [main] ERROR com.techsenger.webserver.core.internal.Activator - Error starting server
java.lang.IllegalStateException: WELD-ENV-002009: Weld SE container cannot be initialized - no bean archives found
?? ?at weld.se.core at 3.0.4.Final/org.jboss.weld.environment.se.Weld.createDeployment(Weld.java:962)
?? ?at weld.se.core at 3.0.4.Final/org.jboss.weld.environment.se.Weld.initialize(Weld.java:773)

Are there any ways to control what modules Weld should scan if we initialize via Weld class?

By the way: STOP creating packages with the same name in different JAR arhives! JPMS doesn't allow it! I had to merge core-impl, spi and api in one file.

Best regards, Alex

>?????, 16 ??? 2018, 16:47 +03:00 ?? Matej Novotny < manovotn at redhat.com >:
>
>Weld 2.x is NOT to be executed with Java 9+.
>Use Weld 3, please. Best use latest release of course (3.0.4.Final).
>
>If you can share the test project on GH, that would be neat as well.
>Then we could see how you use weld as auto module (as well as many other configurations) and go from there.
>
>As for starting SE container, you shouldn't manually call `bootstrap.startContainer(Environments.SE, deployment);`
>Please see the docs on how to bootstrap Weld in SE, you shouldn't need to deal with any of the methods you listed below.
>Here is a doc link -  http://docs.jboss.org/weld/reference/latest-master/en-US/html_single/#_bootstrapping_cdi_se
>
>Regards
>Matej
>
>----- Original Message -----
>> From: "Alex Sviridov" < ooo_saturn7 at mail.ru >
>> To: "weld-dev" < weld-dev at lists.jboss.org >
>> Sent: Wednesday, May 16, 2018 1:51:20 PM
>> Subject: [weld-dev] Staring weld container for SE environment makes me load java ee classes.
>> 
>> Hi all
>> 
>> I am trying to start weld container (2.3.5) as auto module in JPMS. This is
>> my code
>> 
>> Deployment deployment = new Deployment() {
>> @Override
>> public Collection<BeanDeploymentArchive> getBeanDeploymentArchives() {
>> List<BeanDeploymentArchive> list = new ArrayList<>();
>> list.add(archive);
>> return list;
>> }
>> 
>> @Override
>> public BeanDeploymentArchive loadBeanDeploymentArchive(Class<?> beanClass) {
>> throw new UnsupportedOperationException("Not supported yet.");
>> }
>> 
>> @Override
>> public ServiceRegistry getServices() {
>> SimpleServiceRegistry simpleServiceRegistry = new SimpleServiceRegistry();
>> simpleServiceRegistry.add(ResourceLoader.class, new ResourceLoaderImpl());
>> return simpleServiceRegistry;
>> }
>> 
>> @Override
>> public Iterable getExtensions() {
>> return new ArrayList<>();
>> }
>> };
>> 
>> bootstrap.startContainer(Environments.SE, deployment);
>> 
>> The problem is that in BeanDeployment constructor all services are loaded
>> here
>>  https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/bootstrap/BeanDeployment.java#L117
>> and if I in my resource loader service return instead of all java-ee classes
>> null, I get null pointer exception, for example here
>>  https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/ejb/EJBApiAbstraction.java#L44
>> 
>> I can't understand why all these classes are requested from me, as I am in
>> SE. Or I am doing something wrong. Could anyone help me?
>> 
>> --
>> Best regards, Alex Sviridov
>> 
>> _______________________________________________
>> weld-dev mailing list
>>  weld-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/weld-dev


-- 
Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180516/c498bd9f/attachment-0001.html 

From mkouba at redhat.com  Thu May 17 03:12:20 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 17 May 2018 09:12:20 +0200
Subject: [weld-dev] Staring weld container for SE environment makes me
 load java ee classes.
In-Reply-To: <1526493734.103531037@f310.i.mail.ru>
References: <1526471479.117220955@f423.i.mail.ru>
	<1557659196.30311132.1526478454502.JavaMail.zimbra@redhat.com>
	<1526493734.103531037@f310.i.mail.ru>
Message-ID: <4f66a374-c6eb-8cd2-f1dc-8178ecd1f523@redhat.com>

Dne 16.5.2018 v 20:02 Alex Sviridov napsal(a):
> Hi Matej
> 
> I followed your answer and run Weld (SE) as auto module in my JPMS 
> layer. In this layer I have an arhive with beans.xml
> This is my code:
>  ?????? Weld weld = new Weld();
>  ??????? WeldContainer container = weld.initialize();
> 
> This is what I get:
> 
> INFO: WELD-000900: 3.0.4 (Final)
> May 16, 2018 7:00:39 PM 
> org.jboss.weld.environment.deployment.discovery.ReflectionDiscoveryStrategy 
> processAnnotatedDiscovery
> INFO: WELD-ENV-000014: Falling back to Java Reflection for 
> bean-discovery-mode="annotated" discovery. Add org.jboss:jandex to the 
> classpath to speed-up startup.
> 2018-05-16 19:00:39:187 [main] ERROR 
> com.techsenger.webserver.core.internal.Activator - Error starting server
> java.lang.IllegalStateException: WELD-ENV-002009: Weld SE container 
> cannot be initialized - no bean archives found
>  ?? ?at 
> weld.se.core at 3.0.4.Final/org.jboss.weld.environment.se.Weld.createDeployment(Weld.java:962)
>  ?? ?at 
> weld.se.core at 3.0.4.Final/org.jboss.weld.environment.se.Weld.initialize(Weld.java:773)
> 
> Are there any ways to control what modules Weld should scan if we 
> initialize via Weld class?

Weld SE does not support JPMS modules atm. By default, the 
TCCL#getResources() is used to find all beans.xml (if set) or the 
ClassLoader which loaded the WeldResourceLoader.class. However, you can 
provide a custom ClassLoader or 
org.jboss.weld.resources.spi.ResourceLoader respectively (see 
Weld#setClassLoader() and Weld#setResourceLoader()).

> 
> By the way: STOP creating packages with the same name in different JAR 
> arhives! JPMS doesn't allow it! I had to merge core-impl, spi and api in 
> one file.

Which packages are you talking about? We do know about this limitation 
and AFAIK this was fixed in 3.0.0. If there is a duplicit package pls 
create a JIRA issue.

> 
> Best regards, Alex
> 
>     ?????, 16 ??? 2018, 16:47 +03:00 ?? Matej Novotny
>     <manovotn at redhat.com <mailto:manovotn at redhat.com>>:
> 
>     Weld 2.x is NOT to be executed with Java 9+.
>     Use Weld 3, please. Best use latest release of course (3.0.4.Final).
> 
>     If you can share the test project on GH, that would be neat as well.
>     Then we could see how you use weld as auto module (as well as many
>     other configurations) and go from there.
> 
>     As for starting SE container, you shouldn't manually call
>     `bootstrap.startContainer(Environments.SE, deployment);`
>     Please see the docs on how to bootstrap Weld in SE, you shouldn't
>     need to deal with any of the methods you listed below.
>     Here is a doc link -
>     http://docs.jboss.org/weld/reference/latest-master/en-US/html_single/#_bootstrapping_cdi_se
> 
>     Regards
>     Matej
> 
>     ----- Original Message -----
>      > From: "Alex Sviridov" <ooo_saturn7 at mail.ru
>     <//e.mail.ru/compose/?mailto=mailto%3aooo_saturn7 at mail.ru>>
>      > To: "weld-dev" <weld-dev at lists.jboss.org
>     <//e.mail.ru/compose/?mailto=mailto%3aweld%2ddev at lists.jboss.org>>
>      > Sent: Wednesday, May 16, 2018 1:51:20 PM
>      > Subject: [weld-dev] Staring weld container for SE environment
>     makes me load java ee classes.
>      >
>      > Hi all
>      >
>      > I am trying to start weld container (2.3.5) as auto module in
>     JPMS. This is
>      > my code
>      >
>      > Deployment deployment = new Deployment() {
>      > @Override
>      > public Collection<BeanDeploymentArchive>
>     getBeanDeploymentArchives() {
>      > List<BeanDeploymentArchive> list = new ArrayList<>();
>      > list.add(archive);
>      > return list;
>      > }
>      >
>      > @Override
>      > public BeanDeploymentArchive loadBeanDeploymentArchive(Class<?>
>     beanClass) {
>      > throw new UnsupportedOperationException("Not supported yet.");
>      > }
>      >
>      > @Override
>      > public ServiceRegistry getServices() {
>      > SimpleServiceRegistry simpleServiceRegistry = new
>     SimpleServiceRegistry();
>      > simpleServiceRegistry.add(ResourceLoader.class, new
>     ResourceLoaderImpl());
>      > return simpleServiceRegistry;
>      > }
>      >
>      > @Override
>      > public Iterable getExtensions() {
>      > return new ArrayList<>();
>      > }
>      > };
>      >
>      > bootstrap.startContainer(Environments.SE, deployment);
>      >
>      > The problem is that in BeanDeployment constructor all services
>     are loaded
>      > here
>      >
>     https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/bootstrap/BeanDeployment.java#L117
>      > and if I in my resource loader service return instead of all
>     java-ee classes
>      > null, I get null pointer exception, for example here
>      >
>     https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/ejb/EJBApiAbstraction.java#L44
>      >
>      > I can't understand why all these classes are requested from me,
>     as I am in
>      > SE. Or I am doing something wrong. Could anyone help me?
>      >
>      > --
>      > Best regards, Alex Sviridov
>      >
>      > _______________________________________________
>      > weld-dev mailing list
>      > weld-dev at lists.jboss.org
>     <//e.mail.ru/compose/?mailto=mailto%3aweld%2ddev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/weld-dev
> 
> 
> 
> -- 
> Alex Sviridov
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From ooo_saturn7 at mail.ru  Thu May 17 06:50:32 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Thu, 17 May 2018 13:50:32 +0300
Subject: [weld-dev]
 =?utf-8?q?Staring_weld_container_for_SE_environment_ma?=
 =?utf-8?q?kes_me_load_java_ee_classes=2E?=
In-Reply-To: <4f66a374-c6eb-8cd2-f1dc-8178ecd1f523@redhat.com>
References: <1526471479.117220955@f423.i.mail.ru>
	<1526493734.103531037@f310.i.mail.ru>
	<4f66a374-c6eb-8cd2-f1dc-8178ecd1f523@redhat.com>
Message-ID: <1526554232.893807213@f142.i.mail.ru>

Hi Martin,

Could you or someone else explain what is the difference between getResource(String name) and getResources(String name) in ResourceLoader? And, could anyone explain how Weld detects what archives it must scan? For examlpe, if from getResource I return `jar:file:///home/user/../jar/my-archive-0.1.0-SNAPSHOT.jar!/META-INF/beans.xml` , does it mean that Weld will scan my-archive-0.1.0-SNAPSHOT.jar as it will get the path to archive from this URL?

Best regards, Alex

>???????, 17 ??? 2018, 10:12 +03:00 ?? Martin Kouba <mkouba at redhat.com>:
>
>Dne 16.5.2018 v 20:02 Alex Sviridov napsal(a):
>> Hi Matej
>> 
>> I followed your answer and run Weld (SE) as auto module in my JPMS 
>> layer. In this layer I have an arhive with beans.xml
>> This is my code:
>>  ?????? Weld weld = new Weld();
>>  ??????? WeldContainer container = weld.initialize();
>> 
>> This is what I get:
>> 
>> INFO: WELD-000900: 3.0.4 (Final)
>> May 16, 2018 7:00:39 PM 
>> org.jboss.weld.environment.deployment.discovery.ReflectionDiscoveryStrategy 
>> processAnnotatedDiscovery
>> INFO: WELD-ENV-000014: Falling back to Java Reflection for 
>> bean-discovery-mode="annotated" discovery. Add org.jboss:jandex to the 
>> classpath to speed-up startup.
>> 2018-05-16 19:00:39:187 [main] ERROR 
>> com.techsenger.webserver.core.internal.Activator - Error starting server
>> java.lang.IllegalStateException: WELD-ENV-002009: Weld SE container 
>> cannot be initialized - no bean archives found
>>  ?? ?at 
>> weld.se.core at 3.0.4.Final/org.jboss.weld.environment.se.Weld.createDeployment(Weld.java:962)
>>  ?? ?at 
>> weld.se.core at 3.0.4.Final/org.jboss.weld.environment.se.Weld.initialize(Weld.java:773)
>> 
>> Are there any ways to control what modules Weld should scan if we 
>> initialize via Weld class?
>
>Weld SE does not support JPMS modules atm. By default, the 
>TCCL#getResources() is used to find all beans.xml (if set) or the 
>ClassLoader which loaded the WeldResourceLoader.class. However, you can 
>provide a custom ClassLoader or 
>org.jboss.weld.resources.spi.ResourceLoader respectively (see 
>Weld#setClassLoader() and Weld#setResourceLoader()).
>
>> 
>> By the way: STOP creating packages with the same name in different JAR 
>> arhives! JPMS doesn't allow it! I had to merge core-impl, spi and api in 
>> one file.
>
>Which packages are you talking about? We do know about this limitation 
>and AFAIK this was fixed in 3.0.0. If there is a duplicit package pls 
>create a JIRA issue.
>
>> 
>> Best regards, Alex
>> 
>>     ?????, 16 ??? 2018, 16:47 +03:00 ?? Matej Novotny
>>     < manovotn at redhat.com <mailto:manovotn at redhat.com>>:
>> 
>>     Weld 2.x is NOT to be executed with Java 9+.
>>     Use Weld 3, please. Best use latest release of course (3.0.4.Final).
>> 
>>     If you can share the test project on GH, that would be neat as well.
>>     Then we could see how you use weld as auto module (as well as many
>>     other configurations) and go from there.
>> 
>>     As for starting SE container, you shouldn't manually call
>>     `bootstrap.startContainer(Environments.SE, deployment);`
>>     Please see the docs on how to bootstrap Weld in SE, you shouldn't
>>     need to deal with any of the methods you listed below.
>>     Here is a doc link -
>>  http://docs.jboss.org/weld/reference/latest-master/en-US/html_single/#_bootstrapping_cdi_se
>> 
>>     Regards
>>     Matej
>> 
>>     ----- Original Message -----
>>      > From: "Alex Sviridov" < ooo_saturn7 at mail.ru
>>     <//e.mail.ru/compose/?mailto=mailto%3aooo_saturn7 at mail.ru>>
>>      > To: "weld-dev" < weld-dev at lists.jboss.org
>>     <//e.mail.ru/compose/?mailto=mailto%3aweld%2ddev at lists.jboss.org>>
>>      > Sent: Wednesday, May 16, 2018 1:51:20 PM
>>      > Subject: [weld-dev] Staring weld container for SE environment
>>     makes me load java ee classes.
>>      >
>>      > Hi all
>>      >
>>      > I am trying to start weld container (2.3.5) as auto module in
>>     JPMS. This is
>>      > my code
>>      >
>>      > Deployment deployment = new Deployment() {
>>      > @Override
>>      > public Collection<BeanDeploymentArchive>
>>     getBeanDeploymentArchives() {
>>      > List<BeanDeploymentArchive> list = new ArrayList<>();
>>      > list.add(archive);
>>      > return list;
>>      > }
>>      >
>>      > @Override
>>      > public BeanDeploymentArchive loadBeanDeploymentArchive(Class<?>
>>     beanClass) {
>>      > throw new UnsupportedOperationException("Not supported yet.");
>>      > }
>>      >
>>      > @Override
>>      > public ServiceRegistry getServices() {
>>      > SimpleServiceRegistry simpleServiceRegistry = new
>>     SimpleServiceRegistry();
>>      > simpleServiceRegistry.add(ResourceLoader.class, new
>>     ResourceLoaderImpl());
>>      > return simpleServiceRegistry;
>>      > }
>>      >
>>      > @Override
>>      > public Iterable getExtensions() {
>>      > return new ArrayList<>();
>>      > }
>>      > };
>>      >
>>      > bootstrap.startContainer(Environments.SE, deployment);
>>      >
>>      > The problem is that in BeanDeployment constructor all services
>>     are loaded
>>      > here
>>      >
>>  https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/bootstrap/BeanDeployment.java#L117
>>      > and if I in my resource loader service return instead of all
>>     java-ee classes
>>      > null, I get null pointer exception, for example here
>>      >
>>  https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/ejb/EJBApiAbstraction.java#L44
>>      >
>>      > I can't understand why all these classes are requested from me,
>>     as I am in
>>      > SE. Or I am doing something wrong. Could anyone help me?
>>      >
>>      > --
>>      > Best regards, Alex Sviridov
>>      >
>>      > _______________________________________________
>>      > weld-dev mailing list
>>      >  weld-dev at lists.jboss.org
>>     <//e.mail.ru/compose/?mailto=mailto%3aweld%2ddev at lists.jboss.org>
>>      >  https://lists.jboss.org/mailman/listinfo/weld-dev
>> 
>> 
>> 
>> -- 
>> Alex Sviridov
>> 
>> 
>> _______________________________________________
>> weld-dev mailing list
>>  weld-dev at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/weld-dev
>> 
>
>-- 
>Martin Kouba
>Senior Software Engineer
>Red Hat, Czech Republic


-- 
Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180517/fff6cc66/attachment-0001.html 

From mkouba at redhat.com  Thu May 17 08:52:11 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 17 May 2018 14:52:11 +0200
Subject: [weld-dev] Staring weld container for SE environment makes me
 load java ee classes.
In-Reply-To: <1526554232.893807213@f142.i.mail.ru>
References: <1526471479.117220955@f423.i.mail.ru>
	<1526493734.103531037@f310.i.mail.ru>
	<4f66a374-c6eb-8cd2-f1dc-8178ecd1f523@redhat.com>
	<1526554232.893807213@f142.i.mail.ru>
Message-ID: <e9d2c9fc-ac0f-c196-49eb-74d1e6ef5e62@redhat.com>

Dne 17.5.2018 v 12:50 Alex Sviridov napsal(a):
> Hi Martin,
> 
> Could you or someone else explain what is the difference between 
> getResource(String name) and getResources(String name) in 
> ResourceLoader? 

It's similar to java.lang.ClassLoader.getResource(String) and 
java.lang.ClassLoader.getResources(String).

> And, could anyone explain how Weld detects what archives 
> it must scan? For examlpe, if from getResource I return 
> `jar:file:///home/user/../jar/my-archive-0.1.0-SNAPSHOT.jar!/META-INF/beans.xml` 
> , does it mean that Weld will scan my-archive-0.1.0-SNAPSHOT.jar as it 
> will get the path to archive from this URL?

Yes, Weld will attempt to process the referenced bean archive (using all 
registered 
org.jboss.weld.environment.deployment.discovery.BeanArchiveHandler 
instances).

> 
> Best regards, Alex
> 
>     ???????, 17 ??? 2018, 10:12 +03:00 ?? Martin Kouba <mkouba at redhat.com>:
> 
>     Dne 16.5.2018 v 20:02 Alex Sviridov napsal(a):
>      > Hi Matej
>      >
>      > I followed your answer and run Weld (SE) as auto module in my JPMS
>      > layer. In this layer I have an arhive with beans.xml
>      > This is my code:
>      > ?????? Weld weld = new Weld();
>      > ??????? WeldContainer container = weld.initialize();
>      >
>      > This is what I get:
>      >
>      > INFO: WELD-000900: 3.0.4 (Final)
>      > May 16, 2018 7:00:39 PM
>      >
>     org.jboss.weld.environment.deployment.discovery.ReflectionDiscoveryStrategy
> 
>      > processAnnotatedDiscovery
>      > INFO: WELD-ENV-000014: Falling back to Java Reflection for
>      > bean-discovery-mode="annotated" discovery. Add org.jboss:jandex
>     to the
>      > classpath to speed-up startup.
>      > 2018-05-16 19:00:39:187 [main] ERROR
>      > com.techsenger.webserver.core.internal.Activator - Error starting
>     server
>      > java.lang.IllegalStateException: WELD-ENV-002009: Weld SE container
>      > cannot be initialized - no bean archives found
>      > ?? ?at
>      >
>     weld.se.core at 3.0.4.Final/org.jboss.weld.environment.se.Weld.createDeployment(Weld.java:962)
>      > ?? ?at
>      >
>     weld.se.core at 3.0.4.Final/org.jboss.weld.environment.se.Weld.initialize(Weld.java:773)
>      >
>      > Are there any ways to control what modules Weld should scan if we
>      > initialize via Weld class?
> 
>     Weld SE does not support JPMS modules atm. By default, the
>     TCCL#getResources() is used to find all beans.xml (if set) or the
>     ClassLoader which loaded the WeldResourceLoader.class. However, you can
>     provide a custom ClassLoader or
>     org.jboss.weld.resources.spi.ResourceLoader respectively (see
>     Weld#setClassLoader() and Weld#setResourceLoader()).
> 
>      >
>      > By the way: STOP creating packages with the same name in
>     different JAR
>      > arhives! JPMS doesn't allow it! I had to merge core-impl, spi and
>     api in
>      > one file.
> 
>     Which packages are you talking about? We do know about this limitation
>     and AFAIK this was fixed in 3.0.0. If there is a duplicit package pls
>     create a JIRA issue.
> 
>      >
>      > Best regards, Alex
>      >
>      > ?????, 16 ??? 2018, 16:47 +03:00 ?? Matej Novotny
>      > <manovotn at redhat.com <mailto:manovotn at redhat.com>
>     <mailto:manovotn at redhat.com>>:
>      >
>      > Weld 2.x is NOT to be executed with Java 9+.
>      > Use Weld 3, please. Best use latest release of course (3.0.4.Final).
>      >
>      > If you can share the test project on GH, that would be neat as well.
>      > Then we could see how you use weld as auto module (as well as many
>      > other configurations) and go from there.
>      >
>      > As for starting SE container, you shouldn't manually call
>      > `bootstrap.startContainer(Environments.SE, deployment);`
>      > Please see the docs on how to bootstrap Weld in SE, you shouldn't
>      > need to deal with any of the methods you listed below.
>      > Here is a doc link -
>      >
>     http://docs.jboss.org/weld/reference/latest-master/en-US/html_single/#_bootstrapping_cdi_se
>      >
>      > Regards
>      > Matej
>      >
>      > ----- Original Message -----
>      > > From: "Alex Sviridov" <ooo_saturn7 at mail.ru
>     <mailto:ooo_saturn7 at mail.ru>
>      > <//e.mail.ru/compose/?mailto=mailto%3aooo_saturn7 at mail.ru>>
>      > > To: "weld-dev" <weld-dev at lists.jboss.org
>     <mailto:weld-dev at lists.jboss.org>
>      > <//e.mail.ru/compose/?mailto=mailto%3aweld%2ddev at lists.jboss.org>>
>      > > Sent: Wednesday, May 16, 2018 1:51:20 PM
>      > > Subject: [weld-dev] Staring weld container for SE environment
>      > makes me load java ee classes.
>      > >
>      > > Hi all
>      > >
>      > > I am trying to start weld container (2.3.5) as auto module in
>      > JPMS. This is
>      > > my code
>      > >
>      > > Deployment deployment = new Deployment() {
>      > > @Override
>      > > public Collection<BeanDeploymentArchive>
>      > getBeanDeploymentArchives() {
>      > > List<BeanDeploymentArchive> list = new ArrayList<>();
>      > > list.add(archive);
>      > > return list;
>      > > }
>      > >
>      > > @Override
>      > > public BeanDeploymentArchive loadBeanDeploymentArchive(Class<?>
>      > beanClass) {
>      > > throw new UnsupportedOperationException("Not supported yet.");
>      > > }
>      > >
>      > > @Override
>      > > public ServiceRegistry getServices() {
>      > > SimpleServiceRegistry simpleServiceRegistry = new
>      > SimpleServiceRegistry();
>      > > simpleServiceRegistry.add(ResourceLoader.class, new
>      > ResourceLoaderImpl());
>      > > return simpleServiceRegistry;
>      > > }
>      > >
>      > > @Override
>      > > public Iterable getExtensions() {
>      > > return new ArrayList<>();
>      > > }
>      > > };
>      > >
>      > > bootstrap.startContainer(Environments.SE, deployment);
>      > >
>      > > The problem is that in BeanDeployment constructor all services
>      > are loaded
>      > > here
>      > >
>      >
>     https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/bootstrap/BeanDeployment.java#L117
>      > > and if I in my resource loader service return instead of all
>      > java-ee classes
>      > > null, I get null pointer exception, for example here
>      > >
>      >
>     https://github.com/weld/core/blob/d0019511ea776e9c35eab68c4d493c2df882a121/impl/src/main/java/org/jboss/weld/ejb/EJBApiAbstraction.java#L44
>      > >
>      > > I can't understand why all these classes are requested from me,
>      > as I am in
>      > > SE. Or I am doing something wrong. Could anyone help me?
>      > >
>      > > --
>      > > Best regards, Alex Sviridov
>      > >
>      > > _______________________________________________
>      > > weld-dev mailing list
>      > > weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
>      > <//e.mail.ru/compose/?mailto=mailto%3aweld%2ddev at lists.jboss.org>
>      > > https://lists.jboss.org/mailman/listinfo/weld-dev
>      >
>      >
>      >
>      > --
>      > Alex Sviridov
>      >
>      >
>      > _______________________________________________
>      > weld-dev mailing list
>      > weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/weld-dev
>      >
> 
>     -- 
>     Martin Kouba
>     Senior Software Engineer
>     Red Hat, Czech Republic
> 
> 
> 
> -- 
> Alex Sviridov

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From ooo_saturn7 at mail.ru  Thu May 17 10:16:46 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Thu, 17 May 2018 17:16:46 +0300
Subject: [weld-dev] =?utf-8?q?Weld_SE_as_JPSM_auto_module_=28report=29?=
Message-ID: <1526566606.292522831@f303.i.mail.ru>

Hi all,

I am posting the result of solution to make Weld work as JPMS auto module.

In this solution I use only module path. I manually create JPMS layer and add all modules
to it. For Weld I added the following modules:

??? <module file="cdi-api-2.0.jar"/>
?? ?<module file="javax.annotation-api-1.3.2.jar"/>
?? ?<module file="javax.inject-1.jar"/>
??? <module file="javax.interceptor-api-1.2.jar"/>
??? <module file="jboss-classfilewriter-1.2.2.Final.jar"/>
??? <module file="jboss-logging-3.2.1.Final.jar"/>
?? ?<module file="guava-18.0.jar"/>
??? <module file="weld-se-core-3.0.4.Final.jar"/>
?? ?<module file="weld-environment-common-3.0.4.Final.jar"/>
??? <module file="weld-core-impl-3.0.4.Final.jar"/>
??? <module file="weld-spi-3.0.SP3.jar"/>
?? ?<module file="weld-api-3.0.SP3.jar"/>
??? <module file="jandex-2.0.5.Final.jar"/>

Note, that jandex is 2.0.5 but not 2.0.3 as 2.0.3 doesn't work well with java9. Besides Weld modules
I have two modules - in beanModule( here I have my cdi beans + beans.xml) and serverModule (here
I create Weld etc).

In serverModule I have the following code:

Weld builder = new Weld()
??????????????? .property("org.jboss.weld.construction.relaxed", true)
??????????????? .setClassLoader(this.getClass().getClassLoader())
??????????????? .setResourceLoader(new ResourceLoaderImpl());
WeldContainer container = builder.initialize();
BeanManager bm = container.getBeanManager();

This is my ResourceLoaderImpl:

public class ResourceLoaderImpl implements ResourceLoader {

??? private static final String ERROR_LOADING_CLASS = "Error loading class ";

??? @Override
??? public Class<?> classForName(String name) {
??????? try {
??????????? return Class.forName(name);
??????? } catch (ClassNotFoundException e) {
??????????? throw new ResourceLoadingException(ERROR_LOADING_CLASS + name, e);
??????? } catch (LinkageError e) {
??????????? throw new ResourceLoadingException(ERROR_LOADING_CLASS + name, e);
??????? } catch (TypeNotPresentException e) {
??????????? throw new ResourceLoadingException(ERROR_LOADING_CLASS + name, e);
??????? }
??? }

??? @Override
??? public URL getResource(String name) {
??????? try {
??????????? Module module = this.getClass().getModule().getLayer().findModule("beanModule").orElse(null);
??????????? ModuleReference reference = getReference(module);
??????????? Optional<URI> uri = reference.open().find(name);
??????????? if (uri.isPresent()) {
??????????????? return uri.get().toURL();
??????????? } else {
??????????????? return null;
??????????? }
??????? } catch (MalformedURLException ex) {
??????????? ex.printStackTrace();
??????? } catch (IOException ex) {
??????????? ex.printStackTrace();
??????? }
??????? return null;
??? }

??? @Override
??? public Collection<URL> getResources(String name) {
??????? List<URL> result = new ArrayList<>();
?????? //HERE WE NEED MODULE ITERATION
??????? URL url = this.getResource(name);
??????? if (url != null) {
??????????? result.add(url);
??????? }
??????? return result;
??? }

??? @Override
??? public void cleanup() {? }
}

In beanModule in module-info I open packages, that contains beans.

The solution WORKS, via BeanManager I can get whatever bean I need. The only problem is that I can't
understand what I should return in getResouce(String) if I have many modules - what module first I should
return? For example, when weld calls getResource("META-INF/beans.xml") - ?

It would be very interesting to to get some comments.
-- 
Best regards, Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180517/2ebf6f68/attachment.html 

From ooo_saturn7 at mail.ru  Fri May 18 13:52:10 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Fri, 18 May 2018 20:52:10 +0300
Subject: [weld-dev] =?utf-8?q?How_to_use_Weld_servlet_Env_with_Grizzly=3F?=
Message-ID: <1526665930.221975203@f181.i.mail.ru>

Hi all

Could anyone explain how to connect WebappContext that  implements ServletContext, to
Weld servlet env? I've read the code, but still can't understand how to connect SomeContainer,
that implements servlet.Container, EnhancedListener and Grizzly WebappContext? Could anyone
describe main principles how to do it? I would be very thankful.

-- 
Best regards, Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180518/de26649a/attachment-0001.html 

From mkouba at redhat.com  Mon May 21 08:23:30 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 21 May 2018 14:23:30 +0200
Subject: [weld-dev] How to use Weld servlet Env with Grizzly?
In-Reply-To: <1526665930.221975203@f181.i.mail.ru>
References: <1526665930.221975203@f181.i.mail.ru>
Message-ID: <ff0b8a6c-ab01-ba73-c8b4-d45f64c899d2@redhat.com>

Hi Alex,

do you have some publicly available project so that we can discuss a 
real code?

In general, if you want to integrate Weld servlet with a custom servlet 
container:

1. Implement org.jboss.weld.environment.servlet.Container, e.g. 
GrizzlyContainer
   - Container#touch() should return true if a specific container is 
detected
  - Container#initialize() and Container#destroy() can be used to 
init/cleanup the container
  - note that ContainerContext#getManager() returns a BeanManager which 
could be used later, e.g. for dependency injection; you can also obtain 
a BeanManager from the servlet context - see for example [1]

2. Implement a container specific "injection support"
- each servlet container should provide its own SPI - you should 
implement this SPI so that injection into servlets, listeners and 
filters is supported; see for example [2] how undertow support is 
implemented

3. There is no need to "connect" EnhancedListener in any way. It should 
be registeded automatically. However, if you're trying to run an 
embedded servlet container you will need to register 
org.jboss.weld.environment.servlet.Listener manually.

Martin


[1]
https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/undertow/WeldInstanceFactory.java#L56

[2]
https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/undertow/WeldServletExtension.java

Dne 18.5.2018 v 19:52 Alex Sviridov napsal(a):
> Hi all
> 
> Could anyone explain how to connect WebappContext that implements 
> ServletContext, to
> Weld servlet env? I've read the code, but still can't understand how to 
> connect SomeContainer,
> that implements servlet.Container, EnhancedListener and Grizzly 
> WebappContext? Could anyone
> describe main principles how to do it? I would be very thankful.
> 
> -- 
> Best regards, Alex Sviridov
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From ooo_saturn7 at mail.ru  Wed May 23 10:59:22 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Wed, 23 May 2018 17:59:22 +0300
Subject: [weld-dev]
 =?utf-8?q?How_to_use_Weld_servlet_Env_with_Grizzly=3F?=
In-Reply-To: <36c58553-05cf-fbbc-0a58-7134e8100aee@redhat.com>
References: <1526665930.221975203@f181.i.mail.ru>
	<1526913879.971759861@f332.i.mail.ru>
	<36c58553-05cf-fbbc-0a58-7134e8100aee@redhat.com>
Message-ID: <1527087562.344675248@f85.i.mail.ru>

Hi all,

I found out that in order to control instance creating in Grizzly it is necessary
to override some methods in WebappContext. So I created these two classes:
https://github.com/PavelKastornyy/weld-core/tree/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/grizzly ?
However, objects are not injected in servlets as expected. Could anyone of Weld developers comment my code?

Best regards, Alex


>???????????, 21 ??? 2018, 17:49 +03:00 ?? Martin Kouba <mkouba at redhat.com>:
>
>Dne 21.5.2018 v 16:44 Alex Sviridov napsal(a):
>> Hi Martin,
>> 
>> Thank you for your answer. I implemented half of container -
>>  https://github.com/PashaTurok/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/grizzly/GrizzlyContainer.java
>> 
>> and changed WeldServletLifecycle 
>>  https://github.com/PashaTurok/core/blob/20398c204f4e24d2a6f1c1ea3bc1d9381ff8f25f/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/WeldServletLifecycle.java#L363
>> 
>> 
>> To use my Context I do:
>> WebappContext webContext = new WebappContext("WebappContext", "");
>> Listener listener = new Listener();
>> webContext.addListener(listener);
>> webContext.deploy(server);
>> 
>> to add some servlet/filter to Grizzly WITHOUT CDI I do :
>> ServletRegistration registration = 
>> webContext.addServlet("ServletContainer",? (Class<Servlet>) 
>> Class.forName("org.temp.TestServlet"));
>> registration.addMapping("/");
>> 
>> I've looked through undertow WeldServletExtension but can't understand 
>> when and where this extension is called.
>
>In undertow an extension is a service provider of 
>io.undertow.servlet.ServletExtension, loaded automatically during 
>startup (see also java.util.ServiceLoader). You need to find out how and 
>where Grizzly allows to customize the instantiation/injection of 
>components.
>
>> As I understand I need to make Grizzly webContext use CDI, so I need to 
>> make some factory for every
>> servlet/filter/listener that will create instances of them using 
>> BeanManager and make Grizzly to use
>> these factories. But where is the point where these factories will be 
>> used? Could you show me the direction?
>> 
>> Best regards, Alex
>> 
>>     ???????????, 21 ??? 2018, 15:23 +03:00 ?? Martin Kouba
>>     < mkouba at redhat.com >:
>> 
>>     Hi Alex,
>> 
>>     do you have some publicly available project so that we can discuss a
>>     real code?
>> 
>>     In general, if you want to integrate Weld servlet with a custom servlet
>>     container:
>> 
>>     1. Implement org.jboss.weld.environment.servlet.Container, e.g.
>>     GrizzlyContainer
>>      ???- Container#touch() should return true if a specific container is
>>     detected
>>      ??- Container#initialize() and Container#destroy() can be used to
>>     init/cleanup the container
>>      ??- note that ContainerContext#getManager() returns a BeanManager
>>     which
>>     could be used later, e.g. for dependency injection; you can also obtain
>>     a BeanManager from the servlet context - see for example [1]
>> 
>>     2. Implement a container specific "injection support"
>>     - each servlet container should provide its own SPI - you should
>>     implement this SPI so that injection into servlets, listeners and
>>     filters is supported; see for example [2] how undertow support is
>>     implemented
>> 
>>     3. There is no need to "connect" EnhancedListener in any way. It should
>>     be registeded automatically. However, if you're trying to run an
>>     embedded servlet container you will need to register
>>     org.jboss.weld.environment.servlet.Listener manually.
>> 
>>     Martin
>> 
>> 
>>     [1]
>>  https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/undertow/WeldInstanceFactory.java#L56
>> 
>>     [2]
>>  https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/undertow/WeldServletExtension.java
>> 
>>     Dne 18.5.2018 v 19:52 Alex Sviridov napsal(a):
>>      > Hi all
>>      >
>>      > Could anyone explain how to connect WebappContext that implements
>>      > ServletContext, to
>>      > Weld servlet env? I've read the code, but still can't understand
>>     how to
>>      > connect SomeContainer,
>>      > that implements servlet.Container, EnhancedListener and Grizzly
>>      > WebappContext? Could anyone
>>      > describe main principles how to do it? I would be very thankful.
>>      >
>>      > --
>>      > Best regards, Alex Sviridov
>>      >
>>      >
>>      > _______________________________________________
>>      > weld-dev mailing list
>>      >  weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
>>      >  https://lists.jboss.org/mailman/listinfo/weld-dev
>>      >
>> 
>>     -- 
>>     Martin Kouba
>>     Senior Software Engineer
>>     Red Hat, Czech Republic
>> 
>> 
>> 
>> -- 
>> Alex Sviridov
>
>-- 
>Martin Kouba
>Senior Software Engineer
>Red Hat, Czech Republic


-- 
Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180523/551f53bf/attachment.html