Re: [cdi-dev] Today's meeting will be shorter and about SE
by Pete Muir
Have you reported this?
Issues so I can look at the details?
> On 18 Dec 2014, at 13:56, Romain Manni-Bucau <rmannibucau(a)gmail.com> wrote:
>
> Would be great to have portable api jar. We had issues for some ee jars and this is a pain to not have the same behavior depending your coordinates
>
> Le 18 déc. 2014 14:54, "Pete Muir" <pmuir(a)redhat.com <mailto:pmuir@redhat.com>> a écrit :
>
>> On 18 Dec 2014, at 13:48, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> wrote:
>>
>>
>> Le 18 déc. 2014 14:10, "Pete Muir" <pmuir(a)redhat.com <mailto:pmuir@redhat.com>> a écrit :
>> >
>> >
>> >> On 18 Dec 2014, at 07:58, Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>> wrote:
>> >>
>> >>
>> >> On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote:
>> >>>
>> >>> Hi guys,
>> >>>
>> >>> - why shutdown and not AutoClosable?
>> >>
>> >> I like this idea.
>> >>>
>> >>> - about instance: it uses TCCL to load the impls, not sure it is
>> >>> intended but depending the deployment it can be an issue (is this api
>> >>> 100% JavaSE + flat classpath - ie more constrained than JavaSE?) +
>> >>> most of javax SPI creates a new instance each time "creator" is
>> >>> called.
>> >>
>> >> I don't follow. Who uses TCCL?
>> >
>> >
>> > This is exactly the way java.util.ServiceLoader works.
>> >
>> > Note that it doesn’t use the TCCL to load the impl, it uses the TCCL, or the class loader of the API, or the system loader, to load the “CDIProvider”. This CDIProvider can use whatever mechanism it needs to load the actual impl.
>> >
>> > This certainly provides some limitations, but I think writing an OSGi provider that uses some of OSGi’s DI features could work to look up the current CDI container would work here?
>> >
>>
>> If not stored sure. If stored then you can use a provider you dont expect or broker
>>
> The provider is stored. However there is no requirement on the provider to cache/store what it calls in order to load the implementation of the CDI class. So, it might make sense to introduce an extra level of indirection here for OSGi. This doesn’t need to be in the spec though.
>> >>> - Why Booter and not Container (better than factory IMO)? 1) for
>> >>> consistency with other spec, 2) why can I shutdown a booter ;)?
>> >>
>> >> Exactly
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> Romain Manni-Bucau
>> >>> @rmannibucau
>> >>> http://www.tomitribe.com <http://www.tomitribe.com/>
>> >>> http://rmannibucau.wordpress.com <http://rmannibucau.wordpress.com/>
>> >>> https://github.com/rmannibucau <https://github.com/rmannibucau>
>> >>>
>> >>>
>> >>> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>>:
>> >>>>
>> >>>> On 12/18/2014 04:33 AM, John D. Ament wrote:
>> >>>>
>> >>>> I thought today's meeting was pretty good. Based on one of the discussion
>> >>>> points, I wanted to try putting together an interface that described the
>> >>>> boot paradigm. Unfortunately even in Java 8 it doesn't work too well, I
>> >>>> cannot assign a static variable in an interface the way I can in an abstract
>> >>>> class. More importantly, it doesn't give us the private level expectation I
>> >>>> would look for in this case. I best I could come up with using an interface
>> >>>> is:
>> >>>>
>> >>>> public interface CDIBooter {
>> >>>> default BeanManager initialize() {
>> >>>> return initialize(new HashMap<>());
>> >>>> }
>> >>>>
>> >>>> BeanManager initialize(Map<?,?> properties);
>> >>>>
>> >>>> Why BeanManager? I think it would be better to return CDI or its subclass
>> >>>> rather than this low-level SPI. With the CDI class we get more user-friendly
>> >>>> Instance<T> for free. We could also expose Event<T> similarly.
>> >>>>
>> >>>>
>> >>>> void shutdown();
>> >>>>
>> >>>> class BootHolder {
>> >>>>
>> >>>> static CDIBooter instance = null;
>> >>>>
>> >>>> }
>> >>>>
>> >>>> static CDIBooter instance() {
>> >>>> if(BootHolder.instance == null) {
>> >>>> ServiceLoader<CDIBooter> serviceLoader =
>> >>>> ServiceLoader.load(CDIBooter.class);
>> >>>> for(CDIBooter booter : serviceLoader) {
>> >>>> BootHolder.instance = booter;
>> >>>> break;
>> >>>> }
>> >>>> }
>> >>>> return BootHolder.instance;
>> >>>> }
>> >>>> }
>> >>>>
>> >>>> where as the abstract class is a bit briefer, while also being private.
>> >>>>
>> >>>> public abstract class CDIBooter {
>> >>>> public BeanManager initialize() {
>> >>>> return initialize(new HashMap<>());
>> >>>> }
>> >>>>
>> >>>> public abstract BeanManager initialize(Map<?,?> properties);
>> >>>>
>> >>>> public abstract void shutdown();
>> >>>>
>> >>>> private static CDIBooter instance = null;
>> >>>>
>> >>>> public static CDIBooter instance() {
>> >>>> if(instance == null) {
>> >>>> ServiceLoader<CDIBooter> serviceLoader =
>> >>>> ServiceLoader.load(CDIBooter.class);
>> >>>> for(CDIBooter booter : serviceLoader) {
>> >>>> instance = booter;
>> >>>> break;
>> >>>> }
>> >>>> }
>> >>>> return instance;
>> >>>> }
>> >>>> }
>> >>>>
>> >>>> Obviously ignore concurrency issues, etc. It does look to be safer to do an
>> >>>> abstract class, rather than a factory-interface.
>> >>>>
>> >>>> John
>> >>>>
>> >>>>
>> >>>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand
>> >>>> <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote:
>> >>>>>
>> >>>>> Hi all,
>> >>>>>
>> >>>>>
>> >>>>> I have business matter and will have to shorten the meeting tonight (half
>> >>>>> an hour instead of 1h).
>> >>>>>
>> >>>>> I updated the SE doc and Antonio added useful annexes :
>> >>>>> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-w... <https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-w...>
>> >>>>>
>> >>>>> I propose we focus on this in these 30 mn
>> >>>>>
>> >>>>> regards,
>> >>>>>
>> >>>>> 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.
>> >>
>> >>
>> >> _______________________________________________
>> >> 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.
>> >
>> >
>
9 years, 4 months
Re: [cdi-dev] Today's meeting will be shorter and about SE
by Werner Keil
I suppose the part "Specifications that define an SPI" only covers those
under the EE umbrella, though the document is about SE?
Werner
On Thu, Dec 18, 2014 at 1:26 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
>
> Send cdi-dev mailing list submissions to
> 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: Today's meeting will be shorter and about SE (John D. Ament)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 18 Dec 2014 07:26:02 -0500
> From: "John D. Ament" <john.d.ament(a)gmail.com>
> Subject: Re: [cdi-dev] Today's meeting will be shorter and about SE
> To: Jos? Paumard <jose.paumard(a)gmail.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAOqetn-dUX8HP5v9hCYKP-i8eViK69ZXDf0urtqUv1GtL=
> 10RA(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I would recommend that at least some of these comments make their way into
> the google doc. Things like BeanManager come from there.
>
> I simply dropped a huge code snippet in here since there was no easy way to
> include it in the doc.
>
> On Thu, Dec 18, 2014 at 5:57 AM, Jos? Paumard <jose.paumard(a)gmail.com>
> wrote:
> >
> > Yes, there are good use cases for letting the user provide his own ES to
> > have async calls executed in them. They are the same kind of use cases we
> > have for CompletionStage.
> >
> > Jos?
> >
> > 2014-12-18 10:18 GMT+01:00 Romain Manni-Bucau <rmannibucau(a)gmail.com>:
> >>
> >> 2014-12-18 9:58 GMT+01:00 Jos? Paumard <jose.paumard(a)gmail.com>:
> >> > From what we wrote about async events, ES can be submitted through the
> >> > fireAsync call, following the patterns of CompletionStage. We can also
> >> > submit a default ES while building a CDI container (a you wrote), and
> >> if we
> >> > dont the default ES will probably be the default ForkJoinPool.
> >> >
> >> > So we may have more than one ES, making things more complicated than
> the
> >> > pattern you wrote. I think that having the user to close all the ESes
> >> will
> >> > lead to the same pattern again and again :
> >> > for (ES es : cdi.getESes()) {
> >> > myShutdown(es) ;
> >> > }
> >> >
> >>
> >> Sorry I missed something here: how can we get multiple ES? Basically
> >> if CDI needs a ES behing the scene I expect it expose few config like
> >> potential concurrent calls number etc...In such a case I'm not sure if
> >> having multiple ES would be a good idea.
> >>
> >> > I'd prefer to have a cdi.shutdown(), cdi.shudownNow() or
> >> > cdi.awaitTermination(...) or whatever we call those methods, to
> >> encapsulate
> >> > this code. Seems cleaner to me. It might look like CDI is becoming an
> ES
> >> > itself, but it's delegation, not inheritance.
> >> >
> >> >
> >> >
> >> > 2014-12-18 9:28 GMT+01:00 Romain Manni-Bucau <rmannibucau(a)gmail.com>:
> >> >>
> >> >> Why exposing them? When not simply exposing the executor service (in
> >> >> "init" method).
> >> >>
> >> >> CDIContainer cdi =
> >> CDIContainer.init(singletonMap(ExecutorService.class,
> >> >> myEs));
> >> >> // do something awesome
> >> >> shutdownAsIwant(myEs);
> >> >> cdi.close();
> >> >>
> >> >> Would avoid to have a lot of method several users will not care
> about.
> >> >>
> >> >> By default it would do a if (timeout <= 0 ||
> >> >> !defaultEs.awaitTermination(timeout, MILLISECONDS)) { for (Runnable r
> >> >> : defaultEs.shutdownNow()) { try { r.cancel(); } catch(e) { log(e); }
> >> >> } } with timeout a property of the init map with a default in
> >> >> CDIContainer (constant)
> >> >>
> >> >> wdyt?
> >> >>
> >> >>
> >> >> Romain Manni-Bucau
> >> >> @rmannibucau
> >> >> http://www.tomitribe.com
> >> >> http://rmannibucau.wordpress.com
> >> >> https://github.com/rmannibucau
> >> >>
> >> >>
> >> >> 2014-12-18 9:19 GMT+01:00 Jos? Paumard <jose.paumard(a)gmail.com>:
> >> >> > I think we need to think more about how to close the Container.
> >> >> >
> >> >> > We need to take into account the fact that there wil be async
> process
> >> >> > running in ExecutorServices (SE) or ManagedExecutorServices (EE).
> So
> >> the
> >> >> > shutting down the container will mean shutting down these ES too.
> >> >> >
> >> >> > So I think we should need to carefully look at the way ES are
> closed.
> >> >> > The
> >> >> > question being : what do we do with async tasks that are still
> >> running :
> >> >> > should we abruptely interrupt them ? give them a chance to
> complete ?
> >> >> > All
> >> >> > these are exposed in different methods of ES : shutdown(),
> >> shutdownNow()
> >> >> > and
> >> >> > awaitTermination(timeout). Since the container will have to call
> one
> >> of
> >> >> > these methods per ES it will manage, I think we should also expose
> >> them.
> >> >> >
> >> >> > Jos?
> >> >> >
> >> >> >
> >> >> > 2014-12-18 9:14 GMT+01:00 Romain Manni-Bucau <
> rmannibucau(a)gmail.com
> >> >:
> >> >> >>
> >> >> >> ServiceLoader.load(<api>) = ServiceLoader.load(<api>, tccl)
> >> >> >>
> >> >> >> I was thinking to a plain servlet engine (tomcat to not say any
> >> name)
> >> >> >> and CDI container API to boot in webapps. Having cdi API in tomcat
> >> >> >> itself and CDI impl in webapps (Weld in webapp1, OWB in webapp2
> for
> >> >> >> instance). This would mean using one webapp classloader to find
> the
> >> >> >> booter/container. This is fine excepted if the instance is cached.
> >> >> >>
> >> >> >> Same thought in more complicated about OSGi but I guess it is not
> >> yet
> >> >> >> the target.
> >> >> >>
> >> >> >>
> >> >> >> Romain Manni-Bucau
> >> >> >> @rmannibucau
> >> >> >> http://www.tomitribe.com
> >> >> >> http://rmannibucau.wordpress.com
> >> >> >> https://github.com/rmannibucau
> >> >> >>
> >> >> >>
> >> >> >> 2014-12-18 8:58 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com>:
> >> >> >> >
> >> >> >> > On 12/18/2014 08:48 AM, Romain Manni-Bucau wrote:
> >> >> >> >>
> >> >> >> >> Hi guys,
> >> >> >> >>
> >> >> >> >> - why shutdown and not AutoClosable?
> >> >> >> >
> >> >> >> > I like this idea.
> >> >> >> >>
> >> >> >> >> - about instance: it uses TCCL to load the impls, not sure it
> is
> >> >> >> >> intended but depending the deployment it can be an issue (is
> this
> >> >> >> >> api
> >> >> >> >> 100% JavaSE + flat classpath - ie more constrained than
> JavaSE?)
> >> +
> >> >> >> >> most of javax SPI creates a new instance each time "creator" is
> >> >> >> >> called.
> >> >> >> >
> >> >> >> > I don't follow. Who uses TCCL?
> >> >> >> >>
> >> >> >> >> - Why Booter and not Container (better than factory IMO)? 1)
> for
> >> >> >> >> consistency with other spec, 2) why can I shutdown a booter ;)?
> >> >> >> >
> >> >> >> > Exactly
> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Romain Manni-Bucau
> >> >> >> >> @rmannibucau
> >> >> >> >> http://www.tomitribe.com
> >> >> >> >> http://rmannibucau.wordpress.com
> >> >> >> >> https://github.com/rmannibucau
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> 2014-12-18 8:37 GMT+01:00 Jozef Hartinger <jharting(a)redhat.com
> >:
> >> >> >> >>>
> >> >> >> >>> On 12/18/2014 04:33 AM, John D. Ament wrote:
> >> >> >> >>>
> >> >> >> >>> I thought today's meeting was pretty good. Based on one of
> the
> >> >> >> >>> discussion
> >> >> >> >>> points, I wanted to try putting together an interface that
> >> >> >> >>> described
> >> >> >> >>> the
> >> >> >> >>> boot paradigm. Unfortunately even in Java 8 it doesn't work
> too
> >> >> >> >>> well,
> >> >> >> >>> I
> >> >> >> >>> cannot assign a static variable in an interface the way I can
> >> in an
> >> >> >> >>> abstract
> >> >> >> >>> class. More importantly, it doesn't give us the private level
> >> >> >> >>> expectation I
> >> >> >> >>> would look for in this case. I best I could come up with
> using
> >> an
> >> >> >> >>> interface
> >> >> >> >>> is:
> >> >> >> >>>
> >> >> >> >>> public interface CDIBooter {
> >> >> >> >>> default BeanManager initialize() {
> >> >> >> >>> return initialize(new HashMap<>());
> >> >> >> >>> }
> >> >> >> >>>
> >> >> >> >>> BeanManager initialize(Map<?,?> properties);
> >> >> >> >>>
> >> >> >> >>> Why BeanManager? I think it would be better to return CDI or
> its
> >> >> >> >>> subclass
> >> >> >> >>> rather than this low-level SPI. With the CDI class we get more
> >> >> >> >>> user-friendly
> >> >> >> >>> Instance<T> for free. We could also expose Event<T> similarly.
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> void shutdown();
> >> >> >> >>>
> >> >> >> >>> class BootHolder {
> >> >> >> >>>
> >> >> >> >>> static CDIBooter instance = null;
> >> >> >> >>>
> >> >> >> >>> }
> >> >> >> >>>
> >> >> >> >>> static CDIBooter instance() {
> >> >> >> >>> if(BootHolder.instance == null) {
> >> >> >> >>> ServiceLoader<CDIBooter> serviceLoader =
> >> >> >> >>> ServiceLoader.load(CDIBooter.class);
> >> >> >> >>> for(CDIBooter booter : serviceLoader) {
> >> >> >> >>> BootHolder.instance = booter;
> >> >> >> >>> break;
> >> >> >> >>> }
> >> >> >> >>> }
> >> >> >> >>> return BootHolder.instance;
> >> >> >> >>> }
> >> >> >> >>> }
> >> >> >> >>>
> >> >> >> >>> where as the abstract class is a bit briefer, while also being
> >> >> >> >>> private.
> >> >> >> >>>
> >> >> >> >>> public abstract class CDIBooter {
> >> >> >> >>> public BeanManager initialize() {
> >> >> >> >>> return initialize(new HashMap<>());
> >> >> >> >>> }
> >> >> >> >>>
> >> >> >> >>> public abstract BeanManager initialize(Map<?,?>
> >> properties);
> >> >> >> >>>
> >> >> >> >>> public abstract void shutdown();
> >> >> >> >>>
> >> >> >> >>> private static CDIBooter instance = null;
> >> >> >> >>>
> >> >> >> >>> public static CDIBooter instance() {
> >> >> >> >>> if(instance == null) {
> >> >> >> >>> ServiceLoader<CDIBooter> serviceLoader =
> >> >> >> >>> ServiceLoader.load(CDIBooter.class);
> >> >> >> >>> for(CDIBooter booter : serviceLoader) {
> >> >> >> >>> instance = booter;
> >> >> >> >>> break;
> >> >> >> >>> }
> >> >> >> >>> }
> >> >> >> >>> return instance;
> >> >> >> >>> }
> >> >> >> >>> }
> >> >> >> >>>
> >> >> >> >>> Obviously ignore concurrency issues, etc. It does look to be
> >> safer
> >> >> >> >>> to
> >> >> >> >>> do
> >> >> >> >>> an
> >> >> >> >>> abstract class, rather than a factory-interface.
> >> >> >> >>>
> >> >> >> >>> John
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> On Wed Dec 17 2014 at 10:40:44 AM Antoine Sabot-Durand
> >> >> >> >>> <antoine(a)sabot-durand.net> wrote:
> >> >> >> >>>>
> >> >> >> >>>> Hi all,
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>> I have business matter and will have to shorten the meeting
> >> >> >> >>>> tonight
> >> >> >> >>>> (half
> >> >> >> >>>> an hour instead of 1h).
> >> >> >> >>>>
> >> >> >> >>>> I updated the SE doc and Antonio added useful annexes :
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >> >> >> >>>>
> >>
> https://docs.google.com/document/d/1LgsGT-AAlrF72Z5pW4xNQiVjUHGUME46ZmB-w...
> >> >> >> >>>>
> >> >> >> >>>> I propose we focus on this in these 30 mn
> >> >> >> >>>>
> >> >> >> >>>> regards,
> >> >> >> >>>>
> >> >> >> >>>> Antoine
> >> >> >> >>>> _______________________________________________
> >> >> >> >>>> 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.
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> _______________________________________________
> >> >> >> >>> 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.
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> _______________________________________________
> >> >> >> >>> 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.
> >> >> >> >
> >> >> >> >
> >> >> >> _______________________________________________
> >> >> >> 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.
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Java le soir Cours Java en ligne
> >> >> > Twitter Paris JUG Devoxx France
> >> >> > M : +33 6 76 82 91 47
> >> >
> >> >
> >> >
> >> > --
> >> > Java le soir Cours Java en ligne
> >> > Twitter Paris JUG Devoxx France
> >> > M : +33 6 76 82 91 47
> >>
> >
> >
> > --
> > Java le soir <http://blog.paumard.org> Cours Java en ligne
> > <http://blog.paumard.org/cours-tutoriaux/>
> > Twitter <http://twitter.com/#!/JosePaumard> Paris JUG
> > <http://www.parisjug.org> Devoxx France <http://www.devoxx.fr>
> > M : +33 6 76 82 91 47
> >
> > _______________________________________________
> > 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/20141218/dd583504/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 49, Issue 23
> ***************************************
>
9 years, 4 months
PermGen with JBoss add-on
by Antonio Goncalves
Hi all,
The other day on #IRC I mentioned having PermGen issues with the JBossAS
add-on. It's confirmed. During the HoL there are plenty of people who had
the same issue : install the JBoss add-on, start wildfly 8.1, build the
app, deploy it, go to the index.html page (fine), click on an Entity, bang
! PermGen
Alexis Hassler investigated it during the lab (see below). Basically, no
matter what PermGen you set, it's not taken into account.
Again, I really think this add-on should be looked after carefully, it's
very unstable.
Antonio
---------- Forwarded message ----------
From: Alexis Hassler <alexis.hassler(a)gmail.com>
Date: Tue, Nov 11, 2014 at 11:37 AM
Subject: Re: Forge + Wildfly VM arguments
To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
Pas de changement avec
as-setup --server wildfly8 --installDir /opt/java/wildfly-8.1.0.Final/
--jvmargs "-Xmx512m -XX:MaxPermSize=256m"
Alexis
http://www.jtips.info, http://blog.alexis-hassler.com,
http://www.lyonjug.org
2014-11-11 11:22 GMT+01:00 Alexis Hassler <alexis.hassler(a)gmail.com>:
> Avec un wf externe, démarré avec as-start.
>
>
>
>
> Pour info, en démarrant un wf 8.1 en ligne de commande "normale" :
> -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m
> -Djava.net.preferIPv4Stack=true
> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> -Dorg.jboss.boot.log.file=/opt/java/wildfly-8.1.0.Final/standalone/log/server.log
> -Dlogging.configuration=file:/opt/java/wildfly-8.1.0.Final/standalone/configuration/logging.properties
>
> Alexis
> http://www.jtips.info, http://blog.alexis-hassler.com,
> http://www.lyonjug.org
>
>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
9 years, 4 months
Re: [cdi-dev] cdi-dev Digest, Vol 49, Issue 13
by Werner Keil
Fully agree with Pete's assessment.
Unless the (still very experimental and not even used by Co Spec Lead
Oracle anywhere in Java 8;-) new type annotations that are at least in
theory available from Java SE 8 onward were applied, objects are always
mutable
Werner
On Tue, Dec 16, 2014 at 7:21 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
>
> Send cdi-dev mailing list submissions to
> 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. Is the concept of mutable event payload specified
> (Antoine Sabot-Durand)
> 2. Re: Is the concept of mutable event payload specified
> (John D. Ament)
> 3. Re: Is the concept of mutable event payload specified (Pete Muir)
> 4. Re: Is the concept of mutable event payload specified
> (Romain Manni-Bucau)
> 5. Re: Is the concept of mutable event payload specified
> (Thorben Janssen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 16 Dec 2014 17:31:32 +0100
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] Is the concept of mutable event payload specified
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <213B41E0-D73F-4CED-95B0-AFB50451B791(a)sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi guys,
>
>
> Always working on Async event concept and discussion around mutable
> payloads. I was looking where in the spec we specified the fact that fired
> payload are mutable. I red-read chapter 10 (
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events <
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events>) twice and
> didn?t found. I also browsed JIRA and TCK to find any ref to this feature
> and found nothing. On the other hand it is not specified that payload
> should be immutable ;)
>
> I?d be happy if some of you could have a look and see if I missed
> something.
>
> If I?m not wrong, the mutable payload we (including myself) advertise in
> CDI is a non portable feature (I?m the firs surprised here). So I propose
> that :
>
> 1) We decide to write something in the specification about allowing or
> forbidding it (I know some people not happy with this mix between observer
> and visitor pattern)
> 1bis) Should we decide to forbid it by default, we should provide an
> alternative mode to allow people using this unspecified feature
> 2) Forbid it for fireAsync()
>
>
> Thanks for your feedback and your correction if I missed the feature in
> the spec.
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20141216/6aef8552/at...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 495 bytes
> Desc: Message signed with OpenPGP using GPGMail
> Url :
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20141216/6aef8552/at...
>
> ------------------------------
>
> Message: 2
> Date: Tue, 16 Dec 2014 16:44:37 +0000
> From: "John D. Ament" <john.d.ament(a)gmail.com>
> Subject: Re: [cdi-dev] Is the concept of mutable event payload
> specified
> To: Antoine Sabot-Durand <antoine(a)sabot-durand.net>, cdi-dev
> <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAOqetn_YKLsDMC9Rp=
> DVAUYPoaRoAm_Edp31-nXQM9r8rhVQ4w(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> What's the issue w/ fire async and mutable payload? Non-deterministic
> behavior depending on thread?
>
> On Tue Dec 16 2014 at 11:32:53 AM Antoine Sabot-Durand <
> antoine(a)sabot-durand.net> wrote:
>
> > Hi guys,
> >
> >
> > Always working on Async event concept and discussion around mutable
> > payloads. I was looking where in the spec we specified the fact that
> fired
> > payload are mutable. I red-read chapter 10 (
> > http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and
> didn?t
> > found. I also browsed JIRA and TCK to find any ref to this feature and
> > found nothing. On the other hand it is not specified that payload should
> be
> > immutable ;)
> >
> > I?d be happy if some of you could have a look and see if I missed
> > something.
> >
> > If I?m not wrong, the mutable payload we (including myself) advertise in
> > CDI is a non portable feature (I?m the firs surprised here). So I propose
> > that :
> >
> > 1) We decide to write something in the specification about allowing or
> > forbidding it (I know some people not happy with this mix between
> observer
> > and visitor pattern)
> > 1bis) Should we decide to forbid it by default, we should provide an
> > alternative mode to allow people using this unspecified feature
> > 2) Forbid it for fireAsync()
> >
> >
> > Thanks for your feedback and your correction if I missed the feature in
> > the spec.
> >
> > Antoine
> > _______________________________________________
> > 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/20141216/81b4a0a5/at...
>
> ------------------------------
>
> Message: 3
> Date: Tue, 16 Dec 2014 17:39:19 +0000
> From: Pete Muir <pmuir(a)redhat.com>
> Subject: Re: [cdi-dev] Is the concept of mutable event payload
> specified
> To: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <E83F9043-AB42-45A8-B9DC-9853685F761B(a)redhat.com>
> Content-Type: text/plain; charset="utf-8"
>
> I don?t think it?s specified. As objects are, by default in Java, mutable,
> I would assume that payloads are implicitly mutable.
>
> > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> wrote:
> >
> > Hi guys,
> >
> >
> > Always working on Async event concept and discussion around mutable
> payloads. I was looking where in the spec we specified the fact that fired
> payload are mutable. I red-read chapter 10 (
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events <
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events>) twice and
> didn?t found. I also browsed JIRA and TCK to find any ref to this feature
> and found nothing. On the other hand it is not specified that payload
> should be immutable ;)
> >
> > I?d be happy if some of you could have a look and see if I missed
> something.
> >
> > If I?m not wrong, the mutable payload we (including myself) advertise in
> CDI is a non portable feature (I?m the firs surprised here). So I propose
> that :
> >
> > 1) We decide to write something in the specification about allowing or
> forbidding it (I know some people not happy with this mix between observer
> and visitor pattern)
> > 1bis) Should we decide to forbid it by default, we should provide an
> alternative mode to allow people using this unspecified feature
> > 2) Forbid it for fireAsync()
> >
> >
> > Thanks for your feedback and your correction if I missed the feature in
> the spec.
> >
> > Antoine
> > _______________________________________________
> > 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/20141216/00b88212/at...
>
> ------------------------------
>
> Message: 4
> Date: Tue, 16 Dec 2014 18:46:50 +0100
> From: Romain Manni-Bucau <rmannibucau(a)gmail.com>
> Subject: Re: [cdi-dev] Is the concept of mutable event payload
> specified
> To: Pete Muir <pmuir(a)redhat.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CACLE=7PfznX0Qq6HbkUdh999NRBFYgLRcapNBLKn=
> wOmPEO9Xw(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Antoine,
>
> why isn't it portable?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-16 18:39 GMT+01:00 Pete Muir <pmuir(a)redhat.com>:
> > I don?t think it?s specified. As objects are, by default in Java,
> mutable, I
> > would assume that payloads are implicitly mutable.
> >
> > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand <antoine(a)sabot-durand.net
> >
> > wrote:
> >
> > Hi guys,
> >
> >
> > Always working on Async event concept and discussion around mutable
> > payloads. I was looking where in the spec we specified the fact that
> fired
> > payload are mutable. I red-read chapter 10
> > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and
> didn?t
> > found. I also browsed JIRA and TCK to find any ref to this feature and
> found
> > nothing. On the other hand it is not specified that payload should be
> > immutable ;)
> >
> > I?d be happy if some of you could have a look and see if I missed
> something.
> >
> > If I?m not wrong, the mutable payload we (including myself) advertise in
> CDI
> > is a non portable feature (I?m the firs surprised here). So I propose
> that :
> >
> > 1) We decide to write something in the specification about allowing or
> > forbidding it (I know some people not happy with this mix between
> observer
> > and visitor pattern)
> > 1bis) Should we decide to forbid it by default, we should provide an
> > alternative mode to allow people using this unspecified feature
> > 2) Forbid it for fireAsync()
> >
> >
> > Thanks for your feedback and your correction if I missed the feature in
> the
> > spec.
> >
> > Antoine
> > _______________________________________________
> > 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.
> >
> >
> >
> > _______________________________________________
> > 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.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 16 Dec 2014 19:21:48 +0100
> From: Thorben Janssen <thjanssen123(a)gmail.com>
> Subject: Re: [cdi-dev] Is the concept of mutable event payload
> specified
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAE9nDy-o=
> PHg++iQ4vr8ymEm0eH0zEabbHLWf7U-_cX_zBmZYQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> We should be careful with making the payload imutable. I know of several
> applications (and companies) that change the payload to send some
> information back to to the event producer.
> We shouldn't break these apps, if we can solve it in a different way.
>
> --
> *Thorben Janssen*
>
> @thjanssen123 <https://twitter.com/thjanssen123>
> www.thoughts-on-java.org
>
> 2014-12-16 18:46 GMT+01:00 Romain Manni-Bucau <rmannibucau(a)gmail.com>:
> >
> > Hi Antoine,
> >
> > why isn't it portable?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-12-16 18:39 GMT+01:00 Pete Muir <pmuir(a)redhat.com>:
> > > I don?t think it?s specified. As objects are, by default in Java,
> > mutable, I
> > > would assume that payloads are implicitly mutable.
> > >
> > > On 16 Dec 2014, at 16:31, Antoine Sabot-Durand <
> antoine(a)sabot-durand.net
> > >
> > > wrote:
> > >
> > > Hi guys,
> > >
> > >
> > > Always working on Async event concept and discussion around mutable
> > > payloads. I was looking where in the spec we specified the fact that
> > fired
> > > payload are mutable. I red-read chapter 10
> > > (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events) twice and
> > didn?t
> > > found. I also browsed JIRA and TCK to find any ref to this feature and
> > found
> > > nothing. On the other hand it is not specified that payload should be
> > > immutable ;)
> > >
> > > I?d be happy if some of you could have a look and see if I missed
> > something.
> > >
> > > If I?m not wrong, the mutable payload we (including myself) advertise
> in
> > CDI
> > > is a non portable feature (I?m the firs surprised here). So I propose
> > that :
> > >
> > > 1) We decide to write something in the specification about allowing or
> > > forbidding it (I know some people not happy with this mix between
> > observer
> > > and visitor pattern)
> > > 1bis) Should we decide to forbid it by default, we should provide an
> > > alternative mode to allow people using this unspecified feature
> > > 2) Forbid it for fireAsync()
> > >
> > >
> > > Thanks for your feedback and your correction if I missed the feature in
> > the
> > > spec.
> > >
> > > Antoine
> > > _______________________________________________
> > > 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.
> > >
> > >
> > >
> > > _______________________________________________
> > > 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.
> >
> > _______________________________________________
> > 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/20141216/f74fbdb4/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 49, Issue 13
> ***************************************
>
9 years, 4 months
Re: [cdi-dev] PermGen with JBoss add-on
by Antonio Goncalves
Wrong ML ;o)
Antonio
On Wed, Dec 17, 2014 at 2:03 AM, John D. Ament <john.d.ament(a)gmail.com>
wrote:
>
> Add on for? Or wrong mailing list... ? ;-)
>
> On Tue Dec 16 2014 at 3:42:46 PM Antonio Goncalves <
> antonio.goncalves(a)gmail.com> wrote:
>
>> Hi all,
>>
>> The other day on #IRC I mentioned having PermGen issues with the JBossAS
>> add-on. It's confirmed. During the HoL there are plenty of people who had
>> the same issue : install the JBoss add-on, start wildfly 8.1, build the
>> app, deploy it, go to the index.html page (fine), click on an Entity, bang
>> ! PermGen
>>
>> Alexis Hassler investigated it during the lab (see below). Basically, no
>> matter what PermGen you set, it's not taken into account.
>>
>> Again, I really think this add-on should be looked after carefully, it's
>> very unstable.
>>
>> Antonio
>>
>> ---------- Forwarded message ----------
>> From: Alexis Hassler <alexis.hassler(a)gmail.com>
>> Date: Tue, Nov 11, 2014 at 11:37 AM
>> Subject: Re: Forge + Wildfly VM arguments
>> To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
>>
>>
>> Pas de changement avec
>> as-setup --server wildfly8 --installDir /opt/java/wildfly-8.1.0.Final/
>> --jvmargs "-Xmx512m -XX:MaxPermSize=256m"
>>
>>
>> Alexis
>> http://www.jtips.info, http://blog.alexis-hassler.com,
>> http://www.lyonjug.org
>>
>> 2014-11-11 11:22 GMT+01:00 Alexis Hassler <alexis.hassler(a)gmail.com>:
>>
>>> Avec un wf externe, démarré avec as-start.
>>>
>>>
>>>
>>>
>>> Pour info, en démarrant un wf 8.1 en ligne de commande "normale" :
>>> -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m
>>> -Djava.net.preferIPv4Stack=true
>>> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
>>> -Dorg.jboss.boot.log.file=/opt/java/wildfly-8.1.0.Final/standalone/log/server.log
>>> -Dlogging.configuration=file:/opt/java/wildfly-8.1.0.Final/standalone/configuration/logging.properties
>>>
>>> Alexis
>>> http://www.jtips.info, http://blog.alexis-hassler.com,
>>> http://www.lyonjug.org
>>>
>>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect, Java Champion and Pluralsight author
>>
>> Web site <http://www.antoniogoncalves.org> | Twitter
>> <http://twitter.com/agoncal> | LinkedIn
>> <http://www.linkedin.com/in/agoncal> | Pluralsight
>> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
>> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
>> _______________________________________________
>> 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.
>
>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
9 years, 4 months
Unexplained change in behavior between Java EE 6 and Java EE 7
by Steve Millidge
Hi
We are investigating a change in behaviour between Java EE 6 and Java EE 7 and were wondering if this is a bug or a specification change;
If there is a RequestScoped bean and SFSB like below, and I call invokeStatefulService() on the Request Scoped Bean the behaviour changes depending on Java EE version;
On GFv3 and JBoss EAP 6 the method returns "init" implying we have 2 separate SFSB instances.
and on GFv4 and WildFly the method returns "stateFromFirst" implying there is 1 SFSB instance.
I would've imagined that the second result i.e. 1 SFSB as there is 1 client bean which exists for the duration of the call is the correct behaviour. However I am not sure.
As both appservers above use JBoss Weld for CDI is this a Weld bug or did the behaviour change between Java EE 6 and Java EE 7?
@RequestScoped
public class Injection {
@Inject
StatefulService first;
@Inject
StatefulService second;
public String invokeStatefulService(){
first.setState("stateFromFirst");
return second.getState();
}
}
@Stateful
public class StatefulService {
private String state;
@PostConstruct
public void init(){
this.state = "init";
}
public void setState(String state) {
this.state = state;
}
public String getState() {
return state;
}
}
Steve Millidge
Director
C2B2
The Leading Independent Middleware Experts.
T: 08450 539457 | M: 07920 100626 | W: www.c2b2.co.uk<http://www.c2b2.co.uk/> | E: smillidge(a)c2b2.co.uk<mailto:smillidge@c2b2.co.uk>
[Main SIgnature May 14]
---------------------------------------------------------------------------------------------------------------
C2B2 Consulting Limited, Malvern Hills Science Park, Geraldine Road, Malvern, Worcestershire, WR14 3SZ
Registered in England and Wales: 4563419, Registered Office: Ardendale, Old Hollow, Malvern, Worcestershire
9 years, 4 months
Today's meeting agenda
by Antoine Sabot-Durand
Hi guys,
As said before, the discussion in async event workshop is very rich but reached a high level of confusion preventing us to go further on these important features. After getting very precious feedback from José and documenting myself on new asynchronous feature in JDK 8 I rewrote a more broader doc about async operation in CDI 2.0. In this doc I try a new approach to help us take decision step by step.
Once these points discussed, I think it will be easier to get back to Async Event workshop since we’ll have taken basic approach for Async operation in CDI 2.0.
I’m currently working on this doc but you can reach it here
https://docs.google.com/document/d/1pDO7gru6YuEyTDdK3XBozvXZYucT9uC7McZMf... <https://docs.google.com/document/d/1pDO7gru6YuEyTDdK3XBozvXZYucT9uC7McZMf...>
There’s already big decision to make in the beginning of the doc (adoption of JDK 8 CompletableFuture API and support of Async method call). I don’t know if we’ll be able to take these decision in today’s meeting but I propose we use this doc to debate today.
Antoine Sabot-Durand
9 years, 4 months
New Servlet related scope - @UpgradeScoped (?)
by Pavel Bucek
Hi all,
I'm trying to figure out how to solve issue in JSR 356 - Java API for
WebSocket, related to CDI scope usable from WebSocket endpoints. Problem
is, that "standard" scopes do not apply, because there is no
@RequestScoped (http response is already sent), HttpSession does not
need to be created and the rest does not seem to be applicable, ...
I believe that CDI specification should define @UpgradeScoped, which
would cover usages of HttpUpgradeHandler from Servlet API. (Similarly as
it does for @RequestScoped, @SessionScoped, ... )
What are your thoughts about this?
Thanks and regards,
Pavel
9 years, 4 months
