Hi Markus,
Thanks for your feedback, and indeed for all of your active
contributions to the group.
The point was to see if we could get a decent bang from an inexpensive
buck. If we could make bridged improvements to the spec that made enough
people happy, and expend minimal effort, without conflicting with more
complete approaches planned for the future, then it would be a win.
However, if people don't think there is enough value in this, or for
other reasons don't see this as being a good thing, then we can
certainly follow the path of least resistance and not do anything in
this area until we get full modularity support underneath. (It's way
easier, after all.)
Providing me with references reminding me of my previous failed attempts
to get some kind of modularity into EE were unnecessarily just turning
the knife, however ;-)
-Mike
On 29/11/2012 3:11 AM, Markus Eisele wrote:
> Hi Mike,
>
> Thanks for the proposal. It is appreciated. I also have read Davids
> thoughts and try to focus on your initial question. Comments inline:
>
> On 28 November 2012 20:56, michael keith<michael.keith_at_oracle.com> wrote:
>> One way to solve this would be to provide a way for an application to
>> indicate that a bundled library is to be placed on the classpath *logically
>> ahead* of all server libraries. Most app servers offer some proprietary
>> solution to this problem, but there is currently no portable way of doing
>> it. If folks are agreeable then we would like to standardize a solution in
>> EE 7. We would first like to get your input as to whether it is worth doing
>> this, though.
> The "proprietary solution" are used heavily and address a very small
> subset of the true issues people face.
> Especially repackaging and visibility issues of some very common 3rd
> party libraries most often cost hours of debugging time.
> Even with there would be a standardized way for 3rd party libs, I
> think this would simply push some vendor dd entries to the standard
> dd. Nothing more. It would for sure be "more" portable .. but I'm not
> sure if this is the right way to go with the dream of some upcoming
> modularity in some future.
>
>> Given that a) the majority of problem occurrences are due to 3rd
>> party libraries being exposed by the server, and
> I can't second that. 3rd party libraries exposed by a server is
> clearly a bug to me. And yes, I know that even that is more "common
> sense" than a spec requirement.
>
>> b) overriding a Java EE API
>> library is going to introduce a larger problem space than what we would
>> likely be able to solve in the time remaining in Java EE,
> This is the true need for EE! Especially the possibility to exchange
> and foremost update the most common implementations (e.G. JPA, CDI) on
> an per server base is something that draws the most attention with the
> projects I have seen. With the upcoming CDI integration of more and
> more specs I expect this to become even harder in the future.
>
>> If enough people would like to solve the limited scope probem in EE 7 then
>> we will follow up with a proposal and some additional questions.
> I'm in favor of solving this with a more complete approach focused on
> pluggability/upgradability.
> Everything else is wasted time. That topic has been moved from EE6
> onward now probably in EE10 earliest. Let's do it ground up (starting
> concept work today if there is "spare time").
>
> Some discussions from the EG mailinglist for further reference:
> http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2011-09/message/78
> http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2012-07/message/49
>
>
> - M
>