Hi guys,
2016-09-28 21:54 GMT+02:00 Ondrej Mihályi <ondrej.mihalyi_at_gmail.com>:
> Greg, Bill, thanks for the info.
>
> Out of the issues that my previous summary lists as mandatory to target
> Java EE, I see that classloading behavior is planned to be specified by the
> upcoming JCache 1.1 (issues #353 and #358 in the list sent by Greg).
>
> What remains is to define default JNDI names and introduce a cache
> descriptor:
>
> 1. Deciding on JNDI name for CacheManager and CachingProvider should be
> quick and pretty obvious.
>
Is it an option to decide to not do it? I mean default jndi names are quite
an issue by themself in particular when not under control. Caching is
pretty close to tuning so having a default sounds like having something
polluting more than helping. Also integrated with CDI JNDI is pretty
legacy. It was useful with JPA cause of [non-]jta-datasource but for JCache
it doesn't make sense to me.
> 2. Cache descriptor is much more work to do, but there already is a
> proposal and sample impl at https://github.com/Adopt-a-
> JSR/jcache-javaee#cache-descriptor. I suggest to go with something simple
> but usable, and possibly extend in later JCache versions
>
>
Is that so important? Most of the JCache usages I saw were relying on a
very custom configuration for the JCache configuration itself (embed in the
application configuration) and provider specific descriptor loaded from
outside the application to let them be tunable and managed by ops teams.
> I would also try to align the API with Java 8 (e.g. add Cache.stream()
> along with existing Cache.iterator()) and add some CDI qualifiers and
> producers, but that could go to Java EE 9 if not enough time.
>
> Would you please provide feedback on whether the above 2 points plus
> classloading should be sufficient to accept JCache as part of JavaEE? Or
> any other issues come to mind?
>
>
> Cheers,
> Ondrej
>
> 2016-09-28 20:07 GMT+02:00 Bill Shannon <bill.shannon_at_oracle.com>:
>
>> Which is fine, but it means the update overall is *not* an "errata".
>> It's a new version of the spec that includes both API changes and errata.
>> Presumably you'll use the JCP Maintenance Release process for these
>> changes.
>>
>> Just trying to make sure we're all using consistent terminology.
>>
>>
>> Greg Luck wrote on 09/28/16 10:04 AM:
>> > Bill
>> >
>> > Around 80-90% of the changes are errata, as defined. We have a couple
>> of very
>> > minor behaviour changes. No new methods.
>> >
>> > Regards
>> >
>> > Greg Luck
>> >
>> >> On 28 Sep. 2016, at 8:45 am, Bill Shannon <bill.shannon_at_oracle.com
>> >> <mailto:bill.shannon_at_oracle.com>> wrote:
>> >>
>> >> Greg, do you really mean "errata", as described on our JCP processes
>> page [1]?
>> >>
>> >> An errata does not change the RI or the version number of the API.
>> >>
>> >> [1] https://java.net/projects/javaee-spec/pages/JCPProcesses
>> >>
>> >>
>> >> gluck_at_gregluck.com <mailto:gluck_at_gregluck.com> wrote on 09/28/2016
>> 08:35 AM:
>> >>> JCache 1.1 is an errata release. There is nothing new being added.
>> >>>
>> >>> See the list of spec issues targeted here -
>> >>> https://github.com/jsr107/jsr107spec/issues?utf8=✓&q=is%3Ais
>> sue%20miles
>> <https://github.com/jsr107/jsr107spec/issues?utf8=%E2%9C%93&q=is%3Aissue%20miles>
>> >>> tone%3A1.1
>> >>>
>> >
>>
>>
>