<div dir="ltr">Your definition seems to fit the standalone need: libraries = not CDI based code (case of a standalone), the runner class (Mymain) doesnt have to be a CDI bean but has to get injections to launch the CDI code.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2015-03-04 13:59 GMT+01:00 Jozef Hartinger <span dir="ltr"><<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
UnmanagedInstance is provided to make it easier for libraries to
perform dependency injection on classes that are for some reason not
CDI beans. It should not be a substitute for lookup of CDI beans.
Therefore, I do not see UnmanagedInstance fitting here.<div><div class="h5"><br>
<br>
<div>On 03/04/2015 01:47 PM, Romain
Manni-Bucau wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hmm
<div><br>
</div>
<div>I think one of the main point I try to push is we have a
bunch of API to do it already, if we need yet another API to
do the same we have several choices:</div>
<div>- we love creating APIs</div>
<div>- all previous APIs are failures and should be deprecated
or fixed</div>
<div>- there is a full mismatch with embedded and EE case (but
we have existing proofs it is not the case)</div>
<div><br>
</div>
<div>I think we should help user to not be lost between all APIs
and I strongly believe we can't do anything on container to
lookup beans (EJBContainer#getContext was a try which is close
to it but it actually just limited user experience compared to
existing solutions).</div>
<div><br>
</div>
<div>What's the issue with UnmanagedInstance?</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<span style="font-size:small">Romain
Manni-Bucau</span><br>
<a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">2015-03-04 13:43 GMT+01:00 Jozef
Hartinger <span dir="ltr"><<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> The only argument I
found supporting a strict separation of those two APIs is
that it makes it easier to control when a user should or
should not use boot (i.e. it should not be used in EE for
example).<br>
<br>
That's a good argument. It's not however necessarily only
achieved by two separate interfaces but can be as well be
achieved with a subclass, e.g:<br>
- CDI for runtime operations only<br>
- StartedCDI extends CDI (or CDIContainer or whatever -
the name does not matter at this point) for runtime
operations + shutdown.<br>
<br>
Normally, CDI is available only. The boot API however
would return StartedCDI thus allowing a user to shutdown
what they started.
<div>
<div><br>
<br>
<br>
<div>On 03/04/2015 12:24 PM, John D. Ament wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">This is actually based on what we
discussed in one of the EG meetings
<div><br>
</div>
<div><a href="http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html" target="_blank">http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html</a></div>
<div><br>
</div>
<div>John<br>
<br>
<div class="gmail_quote">On Wed, Mar 4, 2015 at
4:05 AM Jozef Hartinger <<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Well
it's nowhere given that we must have two
separate interfaces for this. We can
combine the start/stop API with the
existing one to provide an application
with a single reference representing the
CDI container.</div>
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<div>On 02/28/2015 07:05 PM, John D. Ament
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Maybe I'm misreading, but
I don't see us adding another API to
do the same thing here - we're
introducing new functionality.
<div><br>
</div>
<div>CDIContainer/Loader on
startup/shutdown of the application</div>
<div><br>
</div>
<div>CDI for runtime usage within the
application to interact with the
container.</div>
<div><br>
</div>
<div>John<br>
<br>
<div class="gmail_quote">On Fri, Feb
27, 2015 at 3:40 AM Romain
Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">sure I
fully agree excepted I think
introducing yet another API to
do<br>
the same thing is not good so
super tempting to skip it and
wait for<br>
feedbacks rather than
introducing it eagerly.<br>
<br>
<br>
Romain Manni-Bucau<br>
@rmannibucau<br>
<a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
<a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
<a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
<br>
<br>
2015-02-27 8:05 GMT+01:00 Jozef
Hartinger <<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>>:<br>
> My point is that from the
application perspective, the
user obtains one<br>
> container handle for
eventual shutdown (CDIContainer)
and then looks up a<br>
> different container handle
(CDI) that they can use for real
work (lookup /<br>
> event dispatch / etc.) It
would be cleaner if the
container gave away a<br>
> single handle that can do
all of that.<br>
><br>
><br>
> On 02/26/2015 05:42 PM,
Romain Manni-Bucau wrote:<br>
><br>
> Not sure I get how a CDI
instance can help.<br>
><br>
> But
container.getBeanManager()
sounds nice is not a shortcut
for<br>
> CDI.current().getBm()
otherwise it looks like
duplication to me.<br>
><br>
> Can we make container not
contextual - dont think so? If
so it makes sense<br>
> otherwise I fear it doesnt
add much.<br>
><br>
> Le 26 févr. 2015 16:19,
"Jozef Hartinger" <<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>>
a écrit :<br>
>><br>
>> I like the initialize +
close() combination and the
try-with-resources<br>
>> usage.<br>
>> What looks weird to me
is that at line one you obtain a
container handle:<br>
>><br>
>> try (CDIContainer
container =
CDIContainer.newCDIContai...<br>
>>
CDI.current().getBeanManager()
...<br>
>><br>
>> and then at line two
you call a static method to
perform a container<br>
>> lookup :-/<br>
>><br>
>> An API that allows you
to use the container handle you
already got is way<br>
>> better IMO, e.g.:<br>
>><br>
>> try (CDIContainer
container =
CDIContainer.newCDIContai...<br>
>>
container.getBeanManager()<br>
>><br>
>> If
CDIContainer.newCDIContainer()
returns an CDI instance or its
subclass,<br>
>> we get this easily.<br>
>><br>
>> On 02/26/2015 08:58 AM,
Romain Manni-Bucau wrote:<br>
>>><br>
>>> Hi guys<br>
>>><br>
>>> why note keeping it
simple?<br>
>>><br>
>>> try (CDIContainer
container =
CDIContainer.newCDIContainer(/*
optional<br>
>>> map to configure
vendor features */)) {<br>
>>>
CDI.current().getBeanManager()....<br>
>>> }<br>
>>><br>
>>> Not sure the point
having initialize() + having
shutdown = close<br>
>>> really makes the
API more fluent and modern IMO.<br>
>>><br>
>>> Also to be fully SE
I guess provider() method would
be needed even if<br>
>>> optional (SPI usage
by default):<br>
>>><br>
>>> try (CDIContainer
container =<br>
>>><br>
>>>
CDIContainer.provider("org.jboss.weld.WeldCdiContainerProvider").newCDIContainer())<br>
>>> {<br>
>>>
CDI.current().getBeanManager()....<br>
>>> }<br>
>>><br>
>>> Finally I think
having a kind of getInstance
shortcut could be a plus for<br>
>>> SE:<br>
>>><br>
>>> try (CDIContainer
container =
CDIContainer.newCDIContainer())
{<br>
>>>
container.newInstance(MyAppRunner.class
/* optional qualifiers */<br>
>>> ).run(args);<br>
>>> }<br>
>>><br>
>>> Using container to
get an instance would create the
instance and bind<br>
>>> it to the container
lifecycle (mainly for
predestroy) avoiding this<br>
>>> boilerplate code in
all main which will surely only
be used to launch<br>
>>> a soft.<br>
>>><br>
>>> wdyt?<br>
>>><br>
>>><br>
>>><br>
>>> Romain Manni-Bucau<br>
>>> @rmannibucau<br>
>>> <a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
>>> <a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
>>> <a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
>>><br>
>>><br>
>>> 2015-02-26 8:32
GMT+01:00 Jozef Hartinger <<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>>:<br>
>>>><br>
>>>> Comments inline<br>
>>>><br>
>>>> On 02/25/2015
05:53 PM, John D. Ament wrote:<br>
>>>><br>
>>>> Sorry Jozef,
your email fell into the pits of
google inbox's "smart<br>
>>>> sorting"<br>
>>>> features.<br>
>>>><br>
>>>> On Thu, Feb 12,
2015 at 3:18 AM Jozef Hartinger
<<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Hi John,
comments inline:<br>
>>>>><br>
>>>>><br>
>>>>> On
02/11/2015 06:02 PM, John D.
Ament wrote:<br>
>>>>><br>
>>>>> Jozef,<br>
>>>>><br>
>>>>> Most of
what you see there is taken from
the original doc, since<br>
>>>>> everyone<br>
>>>>> seemed to
be in agreement. I think the
map is just a safeguard in case<br>
>>>>> of<br>
>>>>> additional
boot options available in some
implementations (e.g. I think<br>
>>>>> OWB/OpenEJB
have some options.. currently
OpenEJB supports an embedded<br>
>>>>> CDI<br>
>>>>> boot mode).<br>
>>>>><br>
>>>>> No, I am
fine with the map. What I am
questioning is the type of the<br>
>>>>> map.<br>
>>>>> Usually,
data structures with a similar
purpose use Strings as their<br>
>>>>> keys.<br>
>>>>> This
applies to ServletContext
attributes, InvocationContext
data,<br>
>>>>> Servlet<br>
>>>>>
request/session attributes and
others. I am therefore wondering
whether<br>
>>>>> there is a
usecase for the proposed unbound
key signature or not.<br>
>>>><br>
>>>><br>
>>>> I think that's
more of a placeholder, I was
assuming it would be<br>
>>>>
Map<String,Object> once we
clarify everything.<br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> We spoke a
few times about BeanManager vs
CDI. BeanManager was<br>
>>>>> preferable<br>
>>>>> since
there's no easy way to get the
the instance, CDI is easier to
get<br>
>>>>> and<br>
>>>>> more
aligned with how you would get
it. Usually people expect the<br>
>>>>> BeanManager
to be injected or available via
JNDI, neither would be the<br>
>>>>> case<br>
>>>>> here.<br>
>>>>><br>
>>>>> If CDI 2.0
targets Java SE then this
container initialization API
will<br>
>>>>> become
something that ordinary
application developers use to
start/stop<br>
>>>>> CDI<br>
>>>>> in their
applications. It therefore
cannot be considered an SPI but<br>
>>>>> instead<br>
>>>>> should be
something easy to use. On the
other hand, BeanManager is<br>
>>>>> definitely
an SPI. It is used in extension,
frameworks and generally<br>
>>>>> for<br>
>>>>>
integration. Not much by
applications directly.
Therefore, I don't see<br>
>>>>> how<br>
>>>>> the
container bootstrap API and
BeanManager fit together. IMO
the<br>
>>>>> bootstrap<br>
>>>>> API should
expose something that makes
common tasks (obtaining a<br>
>>>>> contextual<br>
>>>>> reference
and firing and event) easy,
which the CDI class does.<br>
>>>>><br>
>>>>> Plus do not
forget that BeanManager can be
obtained easily using<br>
>>>>>
CDI.getBeanManager().<br>
>>>><br>
>>>><br>
>>>> I'm not
disagreeing. There's a few
things I'd consider:<br>
>>>><br>
>>>> - Is this
mostly for new apps or
existing? If existing, it's
probably<br>
>>>> using<br>
>>>> some internal
API, if new it can use whatever
API we give.<br>
>>>> - I don't want
to return void, we should give
some kind of reference<br>
>>>> into<br>
>>>> the container
when we're done booting.<br>
>>>><br>
>>>> Agreed, we
should not be returning void.<br>
>>>><br>
>>>> - CDI is a one
step retrievable reference,
where as BeanManager is a two<br>
>>>> step
reference. With that said,
BeanManager makes more sense to
return<br>
>>>> here. Another
thought could be we invent some
new class that has both,<br>
>>>> but<br>
>>>> that's really
redundant.<br>
>>>><br>
>>>> Why do you
think BeanManager makes more
sense here? Especially given the<br>
>>>> assumption that
application code is going to
call this init/shutdown<br>
>>>> API, I<br>
>>>> don't see
BeanManager as making more
sense.<br>
>>>><br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> Yes, this
is the container start API.
Sounds like you have some good<br>
>>>>> ideas for
things like XML configuration or
programmatic configuration,<br>
>>>>> both<br>
>>>>> of which
are being tracked under separate
tickets. One idea might be<br>
>>>>> for an<br>
>>>>> optional
param in the map to control
packages to scan/ignore, in that<br>
>>>>> map.<br>
>>>>><br>
>>>>> I am
wondering whether this
configuration should be
something optional<br>
>>>>> built on
top of the bootstrap API or
whether we should consider
making<br>
>>>>> it<br>
>>>>> mandatory.
Either way, we cannot add the
bootstrap API to the spec<br>
>>>>> without<br>
>>>>> explicitly
defining how it behaves. My
implicit assumption of the<br>
>>>>> proposal<br>
>>>>> is that the
container is supposed to scan
the entire classpath for<br>
>>>>> explicit<br>
>>>>> or implicit
bean archives (including e.g.
rt.jar), discover beans, fire<br>
>>>>> extensions,
etc. This worries me as this
default behavior is far from<br>
>>>>> being<br>
>>>>>
lightweight, which CDI for Java
SE initially aimed to be.<br>
>>>><br>
>>>><br>
>>>> Yes, the spec
must be updated to reflect the
behavior of SE mode. I<br>
>>>> plan to<br>
>>>> get that
completely into the google doc
before opening any spec changes<br>
>>>> in a<br>
>>>> PR.<br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> We didn't
want to over load the CDI
interface. It already does a
lot.<br>
>>>>> This is
really SPI code, CDI even though
it's in the spi package is<br>
>>>>> used in<br>
>>>>> a lot of
application code.<br>
>>>>><br>
>>>>> I would
personally prefer to have it all
in one place. Having<br>
>>>>>
CDIContainer,
CDIContainerLoader, CDI and
CDIProvider makes it more<br>
>>>>> difficult
to know when to use what.<br>
>>>><br>
>>>><br>
>>>> The problem is
that most CDI (the interface)
operations are against a<br>
>>>> running
container. I think we spoke
about leveraging CDIProvider at
one<br>
>>>> point (in fact,
I mistakenly called CDIContainer
CDIProvider not even<br>
>>>> realizing it
was there). I doubt that most
app developers use it<br>
>>>> currently,<br>
>>>> there's not
even a way to get a reference to
it that I'm aware of. It's<br>
>>>> used by the
implementor only.<br>
>>>><br>
>>>> I don't think
there's a conflict. CDI class
would still only provide<br>
>>>> methods<br>
>>>> to be run
against a running container. The
difference is that there<br>
>>>> would be<br>
>>>> additional
static methods to get this
running container (CDI class) to<br>
>>>> you<br>
>>>> by starting the
container.<br>
>>>><br>
>>>> Either way, I
agree that reusing CDIProvider
is a must. There is no<br>
>>>> reason<br>
>>>> to define a new
class for the same purpose.<br>
>>>><br>
>>>><br>
>>>> I expect that
my changes in the CDI spec
around this will state, along<br>
>>>> the<br>
>>>> lines of:<br>
>>>><br>
>>>> To retrieve a
CDIContainer to launch, do this:<br>
>>>><br>
>>>> CDIContainer
container =
CDIContainerLocator.getCDIContainer();<br>
>>>>
container.initialize();<br>
>>>> ... do work<br>
>>>><br>
>>>> Once you want
to shutdown the container, do
this:<br>
>>>><br>
>>>>
container.shutdown();<br>
>>>><br>
>>>> (we may want to
consider implementing
AutoCloseable, an oversight on
my<br>
>>>> part)<br>
>>>><br>
>>>> and then later
on<br>
>>>><br>
>>>> - What happens
if I call CDIContainerLocator in
an app server<br>
>>>><br>
>>>> - It throws an
IllegalStateException.<br>
>>>><br>
>>>> - The container
provides no beans of type
CDIContainer, it is managed<br>
>>>> outside of the
CDI container.<br>
>>>><br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> John<br>
>>>>><br>
>>>>> On Wed Feb
11 2015 at 4:21:50 AM Jozef
Hartinger <<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>> Hi
John, some thoughts:<br>
>>>>>><br>
>>>>>> -
instead of using BeanManager it
makes more sense to me to return
a<br>
>>>>>> CDI<br>
>>>>>>
instance, which is a more
user-friendly API (and it also
exposes<br>
>>>>>> access
to<br>
>>>>>>
BeanManager)<br>
>>>>>> - is
there a usecase for arbitrary
keys of the "params" map or is<br>
>>>>>>
Map<String, ?> sufficient?<br>
>>>>>> - if we
could move the shutdown() method
from CDIContainer to the<br>
>>>>>> actual<br>
>>>>>>
container handle that we obtain
from initialize(), that would
look<br>
>>>>>> more<br>
>>>>>>
object-oriented<br>
>>>>>> - what
exactly is initialize() supposed
to do? Is it supposed to start<br>
>>>>>>
scanning the entire classpath
for CDI beans? That could be a
problem<br>
>>>>>>
especially with spring-boot-like
fat jars. I think we need an API
to<br>
>>>>>> tell<br>
>>>>>> the
container which classes /
packages to consider. Something
like<br>
>>>>>> Guice's<br>
>>>>>> binding
API perhaps?<br>
>>>>>><br>
>>>>>> - the
proposal makes me wonder whether
retrofitting this functionality<br>
>>>>>> to<br>
>>>>>> the CDI
class wouldn't be a better
option. It could look like:<br>
>>>>>><br>
>>>>>> CDI
container = CDI.initialize();<br>
>>>>>>
container.select(Foo.class).get();<br>
>>>>>>
container.shutdown();<br>
>>>>>><br>
>>>>>> compare
it to:<br>
>>>>>><br>
>>>>>>
CDIContainer container =
CDIContainerLoader.
getCDIContainer();<br>
>>>>>>
BeanManager manager =
container.initialize();<br>
>>>>>>
manager.getBeans(...);<br>
>>>>>>
container.shutdown(manager);<br>
>>>>>><br>
>>>>>><br>
>>>>>> On
02/10/2015 06:58 PM, John D.
Ament wrote:<br>
>>>>>><br>
>>>>>> All,<br>
>>>>>><br>
>>>>>> I have
the updated API here, and wanted
to solicit any final feedback<br>
>>>>>> before
updating the google doc and spec
pages.<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> <a href="https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c" target="_blank">https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c</a><br>
>>>>>><br>
>>>>>> Let me
know your thoughts.<br>
>>>>>><br>
>>>>>> Thanks,<br>
>>>>>><br>
>>>>>> John<br>
>>>>>><br>
>>>>>><br>
>>>>>>
_______________________________________________<br>
>>>>>> cdi-dev
mailing list<br>
>>>>>> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>>>>>><br>
>>>>>> Note
that for all code provided on
this list, the provider licenses<br>
>>>>>> the<br>
>>>>>> code
under the Apache License,
Version 2<br>
>>>>>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all other ideas<br>
>>>>>>
provided on this list, the
provider waives all patent and
other<br>
>>>>>>
intellectual<br>
>>>>>>
property rights inherent in such
information.<br>
>>>>>><br>
>>>>>><br>
>>>><br>
>>>>
_______________________________________________<br>
>>>> cdi-dev mailing
list<br>
>>>> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>>>><br>
>>>> Note that for
all code provided on this list,
the provider licenses the<br>
>>>> code<br>
>>>> under the
Apache License, Version 2<br>
>>>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all other ideas<br>
>>>> provided on
this list, the provider waives
all patent and other<br>
>>>> intellectual<br>
>>>> property rights
inherent in such information.<br>
>><br>
>><br>
><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>