On 18 Dec 2014, at 07:58, Jozef Hartinger <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?

- 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@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@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-wwF35Yw/edit?usp=sharing

I propose we focus on this in these 30 mn

regards,

Antoine
_______________________________________________
cdi-dev mailing list
cdi-dev@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@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@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@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.