[cdi-dev] Feedback - CDI bootstrap API (CDI-26)

Wed Mar 4 09:48:31 EST 2015

Sure but since the path from main(String[]) to CDI is actually this one it
can be the solution. This is not the general way to use CDI but the way to
enter CDI for me, then you simply use @Inject.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-03-04 15:46 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:

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