[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-456:
-------------------------------------
{quote}Class<?> is not enough to know from which module you are so it is not usable (OSGi or EE).{quote}
Why not? And if not how otherwise should the CDI impl know which module the custom Bean<T> belongs to?
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-456:
----------------------------------
[~struberg] What do you mean "WAR files add a Bean with the same class"? By means of a portable extension?
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-456:
----------------------------------------
Class<?> is not enough to know from which module you are so it is not usable (OSGi or EE). I tend to be agree with Mark, beanClass can be the producer class but there is no custom producer in CDI - a "custom producer" is a custom Bean<?> so it knows which type to return. So +1 to force bean class to return the instance type for custom Beans
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-456:
-------------------------------------
Why would you return the same bean class in all the three cases?
If each WAR bundled a class with a producer method each producing this shared type (let's call it S), these producers would not have S as their bean class for exactly this reason ;-)
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-456:
-----------------------------------
Sorry, seems my explanation was too brief ;)
Imagine you have an EAR with 3 WARs. Each of the WAR files add a Bean with the same class (which is in a shared ear lib), but with different bean attributes and different content.
The beanclass would be the same for all the 3 Bean<T>, but they are still in 3 totally different EE modules.
What means getBeanClass() is not usable to distinct the EE modules.
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-456:
-------------------------------------
Why not? And why should we restrict this to single WebApp and ignore multi-module scenarios?
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-456:
-----------------------------------
But Jozef, this is broken for all manually added Beans. E.g. consider you add a Bean<T> in just one single WebApp. Detecting the module by by only using getBeanClass() just doesn't work.
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-456?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-456:
-------------------------------------
The reason why getBeanClass() is defined as it is is modularity. In CDI the concept of "bean class" is used to determine whether a bean in module A is visible to a different bean in module B or not. For producer methods and fields it is the declaring class that determines this, not the return type.
If you for example have an EAR with multiple wars and one of them defines Foo.class:
{code:JAVA}
public class Foo {
@Produces
String foo() {
return "foo";
}
}
{code}
You want to use Foo.class (the declaring class) to determine visibility of the producer method, not String.class (the return type) as otherwise your producer would be visible from all the other WARs! This is especially the case for custom beans where you have no knowledge if the custom bean represents a producer field/method or not. See section 5.1. Modularity for details.
> fix Bean#getBeanClass() definition
> ----------------------------------
>
> Key: CDI-456
> URL: https://issues.jboss.org/browse/CDI-456
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Reporter: Mark Struberg
>
> currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
> Imo this only causes troubles and doesn't add any benefit.
> * At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
> * At the time we create interceptors we ONLY need the type which is to be created;
> * At the time we create the normalscoping proxies we ONLY need the type which is to be created;
> In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
> In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (CDI-456) fix Bean#getBeanClass() definition
by Mark Struberg (JIRA)
Mark Struberg created CDI-456:
---------------------------------
Summary: fix Bean#getBeanClass() definition
Key: CDI-456
URL: https://issues.jboss.org/browse/CDI-456
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Reporter: Mark Struberg
currently Bean#getBeanClass() is defined to return the class of the bean it produces but has one important exception: in case of a producer method or field it must return the class of the owner bean of this method or field.
Imo this only causes troubles and doesn't add any benefit.
* At the time when 'using' the Bean (create and destroy) we always ONLY need the type which is to be created.
* At the time we create interceptors we ONLY need the type which is to be created;
* At the time we create the normalscoping proxies we ONLY need the type which is to be created;
In fact the only time we need the ownerBean is when scanning the methods and fields in it. And for creating we really need the owner-Bean and not it's bean-class!
In OWB we worked around this by having our own method getReturnType() which consistently returns the type which gets created.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
Re: [cdi-dev] cdi-dev Digest, Vol 46, Issue 6
by Werner Keil
I am registered with Freenode, that also recognizes my alias, but trying to
enter #cdi-dev fails with an error:
#cdi-dev Cannot join channel (+r) - you need to be identified with services
Any idea how to fix this?
Thanks,
Werner
cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: cdi-dev Digest, Vol 46, Issue 1 (Mark Paluch)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 3 Sep 2014 18:09:00 +0200
> From: Mark Paluch <mpaluch(a)paluch.biz>
> Subject: Re: [cdi-dev] cdi-dev Digest, Vol 46, Issue 1
> To: Werner Keil <werner.keil(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <775F4479-78CD-4B7A-BDF0-873494FCCE74(a)paluch.biz>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Werner,
> the meeting is today (18:00 CEST) on #cdi-dev.
>
> You?ll have to register with freenode, I guess. No other special
> credentials needed.
>
> Best regards, Mark
>
> > Am 03.09.2014 um 18:03 schrieb Werner Keil <werner.keil(a)gmail.com>:
> >
> > Hi,
> >
> > Is the call taking place today?
> > I seem to be the only one in the Hangout<35F.gif>
> > IRC also gives troubles, the #cdi-dev room does not let me in for now.
> Is there any credential or user name you need to know to let us join?
> >
> > Thanks,
> > Werner
> >
> > On Mon, Sep 1, 2014 at 3:24 PM, <cdi-dev-request(a)lists.jboss.org
> <mailto:cdi-dev-request@lists.jboss.org>> wrote:
> > Send cdi-dev mailing list submissions to
> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.jboss.org/mailman/listinfo/cdi-dev <
> https://lists.jboss.org/mailman/listinfo/cdi-dev>
> > or, via email, send a message with subject or body 'help' to
> > cdi-dev-request(a)lists.jboss.org <mailto:
> cdi-dev-request(a)lists.jboss.org>
> >
> > You can reach the person managing the list at
> > cdi-dev-owner(a)lists.jboss.org <mailto:
> cdi-dev-owner(a)lists.jboss.org>
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of cdi-dev digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 - 19:00 (ASD
> > Perso) (Antoine Sabot-Durand)
> > 2. [JBoss JIRA] (CDI-45) Optional Injection Points
> > (Antoine Sabot-Durand (JIRA))
> > 3. Re: Spec launch meeting and CDI weekly meeting (Filipe Portes)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Mon, 01 Sep 2014 09:47:52 +0000
> > From: Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:
> antoine(a)sabot-durand.net>>
> > Subject: [cdi-dev] Invitation: CDI meeting @ Wed 3 Sep 2014 18:00 -
> > 19:00 (ASD Perso)
> > To: "cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>" <
> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
> > Message-ID: <001a11c38b1c7c974f0501fde5be(a)google.com <mailto:
> 001a11c38b1c7c974f0501fde5be(a)google.com>>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > You have been invited to the following event.
> >
> > Title: CDI meeting
> > When: Wed 3 Sep 2014 18:00 - 19:00 Paris
> > Where: #cdi-dev on freenode IRC
> > Video call: https://plus.google.com/hangouts/_/sabot-durand.net/antoine
> <https://plus.google.com/hangouts/_/sabot-durand.net/antoine>
> > <
> https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2l...
> <
> https://plus.google.com/hangouts/_/sabot-durand.net/antoine?hceid=YW50b2l...
> >>
> > Calendar: ASD Perso
> > Who:
> > * Antoine Sabot-Durand- organiser
> > * cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> >
> > Event details:
> >
> https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I...
> <
> https://www.google.com/calendar/event?action=VIEW&eid=ampuMWI2amVjbjIxa2I...
> >
> >
> > Invitation from Google Calendar: https://www.google.com/calendar/ <
> https://www.google.com/calendar/>
> >
> > You are receiving this courtesy email at the account
> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> because you
> are an attendee of this event.
> >
> > To stop receiving future notifications for this event, decline this
> event.
> > Alternatively, you can sign up for a Google account at
> > https://www.google.com/calendar/ <https://www.google.com/calendar/> and
> control your notification settings for
> > your entire calendar.
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/at...
> <
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/at...
> >
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: not available
> > Type: text/calendar
> > Size: 1074 bytes
> > Desc: not available
> > Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/at...
> <
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/at...
> >
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: invite.ics
> > Type: application/ics
> > Size: 1102 bytes
> > Desc: not available
> > Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/at...
> <
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/4f2d5560/at...
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Mon, 1 Sep 2014 05:55:00 -0400 (EDT)
> > From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org <mailto:
> issues(a)jboss.org>>
> > Subject: [cdi-dev] [JBoss JIRA] (CDI-45) Optional Injection Points
> > To: cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> > Message-ID:
> > <JIRA.12428685.1295838622000.20248.1409565300619(a)Atlassian.JIRA>
> > Content-Type: text/plain; charset=UTF-8
> >
> >
> > [
> https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys...
> <
> https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys...>
> ]
> >
> > Antoine Sabot-Durand updated CDI-45:
> > ------------------------------------
> > Fix Version/s: 2.0 (discussion)
> > (was: TBD)
> >
> >
> > > Optional Injection Points
> > > -------------------------
> > >
> > > Key: CDI-45
> > > URL: https://issues.jboss.org/browse/CDI-45 <
> https://issues.jboss.org/browse/CDI-45>
> > > Project: CDI Specification Issues
> > > Issue Type: Feature Request
> > > Components: Resolution
> > > Affects Versions: 1.0
> > > Reporter: Stuart Douglas
> > > Fix For: 2.0 (discussion)
> > >
> > >
> > > There are occoasions where it may be useful for some injection points
> to be optional, e.g.
> > > @Inject
> > > @Optional
> > > MyBean bean;
> > > This would behave the same as a normal injection point, however it
> will not cause the deployment to fail if it is not satisified.
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.1#6329)
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Mon, 1 Sep 2014 10:24:37 -0300
> > From: Filipe Portes <omeuefilipe(a)gmail.com <mailto:omeuefilipe@gmail.com
> >>
> > Subject: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting
> > To: Mark Paluch <mpaluch(a)paluch.biz <mailto:mpaluch@paluch.biz>>
> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
> > Message-ID:
> > <CAKwwkgQHmM0Gvr=hW=GdU65bfGY+2Z4-PWpRp0Fqu=
> Xhv_hngQ(a)mail.gmail.com <mailto:Xhv_hngQ@mail.gmail.com>>
> > Content-Type: text/plain; charset="utf-8"
> >
> > here in brazil 16:00 UTC equals to 1:00 pm, so it's pretty good.
> >
> >
> > On Sat, Aug 30, 2014 at 9:00 AM, Mark Paluch <mpaluch(a)paluch.biz
> <mailto:mpaluch@paluch.biz>> wrote:
> >
> > > Either way is fine with me. In general 16:00 UTC is a good choice
> since it
> > > seems not to be mid-might for anyone that is involved.
> > >
> > > Best regards, Mark
> > >
> > > Am 30.08.2014 um 12:53 schrieb Thorben Janssen <thjanssen123(a)gmail.com
> <mailto:thjanssen123@gmail.com>>:
> > >
> > > Wednesday at the same time is fine for me.
> > > Do you want to shift all meetings or only this one?
> > >
> > > Regards,
> > > Thorben
> > > ------------------------------
> > > Von: Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:
> antoine(a)sabot-durand.net>>
> > > Gesendet: ?30.?08.?2014 12:18
> > > An: John D. Ament <john.d.ament(a)gmail.com <mailto:
> john.d.ament(a)gmail.com>>
> > > Cc: cdi-dev <cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
> > > Betreff: Re: [cdi-dev] Spec launch meeting and CDI weekly meeting
> > >
> > > Hi John,
> > >
> > > Sorry to have missed that. According to Pete, French are holidays
> > > specialists. I guess I have to improve my expertise in this domain ;).
> > >
> > > Is it ok for everybody to switch the meeting on Wednesday at the same
> > > time ? If there ware no objection I will send you an invitation Monday.
> > >
> > >
> > >
> > > Antoine
> > >
> > > Le 29 ao?t 2014 ? 18:53, John D. Ament <john.d.ament(a)gmail.com
> <mailto:john.d.ament@gmail.com>> a ?crit :
> > >
> > > Could it be pushed to later in the week? Monday's a holiday in the US.
> > >
> > >
> > > On Fri, Aug 29, 2014 at 9:32 AM, Antoine Sabot-Durand <
> > > antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote:
> > >
> > >> Hi All,
> > >>
> > >> On CDI 1.1, we use to have a weekly meeting each monday at 16:00 UTC
> > >> (that?s 9:00 am PDT, 6:00 pm CEST and 9:30 pm IST). It?s hard to
> find a
> > >> time slot that please everybody (from US West Coast to India), so Ir
> > >> propose we keep this track. Now, if you have issue with this slot (if
> you
> > >> live in New Zealand or Australia) say it and we?ll try to figure out a
> > >> better slot (even if there?s no ideal one).
> > >>
> > >> The meeting place is the IRC channel and last one hour. We use an IRC
> bot
> > >> (jbott) to keep track of meeting minutes for the record or people
> unable to
> > >> attend the meeting. You can get familiarised with BOT commands here :
> > >> https://wiki.debian.org/MeetBot <https://wiki.debian.org/MeetBot>
> > >>
> > >> So I propose we have our JSR launch meeting next monday (sept 1st)
> with
> > >> the following agenda :
> > >>
> > >> - Discussion on the working method and tools used (mainly do we use
> > >> Google Drive or Github with Asciidoc for working doc)
> > >> - Discussion on each workshop I mentioned in my previous post and
> missing
> > >> workshop
> > >> * Workshop teams
> > >> * Workflow chosen
> > >> * estimated deadline (hard to say since we don?t know our workforce,
> but
> > >> will be refined later)
> > >> - Q & A if we still have time
> > >>
> > >> Note that It think we should avoid talking about specific content of
> > >> workshop except if you think things are missing or that we could
> forgot
> > >> them.
> > >> If you want to see other points in the agenda let me know.
> > >>
> > >> I?m thrilled to start this great project with you guys.
> > >>
> > >> Antoine
> > >>
> > >> _______________________________________________
> > >> cdi-dev mailing list
> > >> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> > >> https://lists.jboss.org/mailman/listinfo/cdi-dev <
> https://lists.jboss.org/mailman/listinfo/cdi-dev>
> > >>
> > >> Note that for all code provided on this list, the provider licenses
> the
> > >> code under the Apache License, Version 2 (
> > >> http://www.apache.org/licenses/LICENSE-2.0.html <
> http://www.apache.org/licenses/LICENSE-2.0.html>). For all other ideas
> > >> provided on this list, the provider waives all patent and other
> > >> intellectual property rights inherent in such information.
> > >>
> > >
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev <
> https://lists.jboss.org/mailman/listinfo/cdi-dev>
> > >
> > > Note that for all code provided on this list, the provider licenses the
> > > code under the Apache License, Version 2 (
> > > http://www.apache.org/licenses/LICENSE-2.0.html <
> http://www.apache.org/licenses/LICENSE-2.0.html>). For all other ideas
> > > provided on this list, the provider waives all patent and other
> > > intellectual property rights inherent in such information.
> > >
> > >
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev <
> https://lists.jboss.org/mailman/listinfo/cdi-dev>
> > >
> > > Note that for all code provided on this list, the provider licenses the
> > > code under the Apache License, Version 2 (
> > > http://www.apache.org/licenses/LICENSE-2.0.html <
> http://www.apache.org/licenses/LICENSE-2.0.html>). For all other ideas
> > > provided on this list, the provider waives all patent and other
> > > intellectual property rights inherent in such information.
> > >
> >
> >
> >
> > --
> > Filipe Portes - @filipeportes
> > Senior Java EE/Web
> > JUGLeader Gojava <http://www.gojava.org/ <http://www.gojava.org/>> -
> @gojava
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/at...
> <
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140901/57990ba6/at...
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/cdi-dev <
> https://lists.jboss.org/mailman/listinfo/cdi-dev>
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html <
> http://www.apache.org/licenses/LICENSE-2.0.html>). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
> >
> > End of cdi-dev Digest, Vol 46, Issue 1
> > **************************************
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20140903/f229b1b4/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 46, Issue 6
> **************************************
>
9 years, 8 months