You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by David Boyer <ma...@gmail.com> on 2010/01/14 19:19:54 UTC
JUEL usage
We're concerned about JUEL and whether it passes the TCK for JSR-245.
If it doesn't we can't ship it with our Enterprise product. This is a
big concern to us. The unfortunate part is that shindig uses JUEL
specific classes and interfaces instead of sticking to the base EL
interfaces in the Expression Language API, defined by javax.el.
Does anyone know, or can anyone shed any light on this library?
Thanks,
--
David S Boyer
mangr3n@gmail.com
703.499.8728(h)
703.408.5395(m)
Re: JUEL usage
Posted by Paul Lindner <li...@inuus.com>.
this is a tricky situation..
If we remove juel from the distribution then we must rely on people
deploying shindig in a JSP 2.1 compliant container to access the javax.el
apis, which effectively shuts out a large amount of deployment scenarios.
I'd appreciate it if you (or anyone else) could look into making shindig use
native javax.el apis instead of juel APIs, while maintaining juel as the
default implementation...
On Mon, Jan 18, 2010 at 10:31 AM, David Boyer <ma...@gmail.com> wrote:
> Question was asked and answered. Juel is in fact an issue for us.
>
> http://juel.sourceforge.net/
> We are Java-Certified, we can't ship our products with a library that
> doesn't pass a TCK if it implements a JSR. We're going to test this
> over the next week or so. I have to track down the TCK and run it
> against JUEL, this may not be that simple since the JSR is larger than
> just the Expression Language API. My concern is that if it passed
> the TCK, the site would most likely state it.
>
> On the shindig side the issue is that shindig uses implementation
> specific classes that are not part of the javax.el namespace. So
> shindig is tied directly to JUEL, not just the javax.el namespace. If
> we can't ship that code, we're going to have to find a way to replace
> JUEL with a lib that will pass the TCK. In addition, we would have to
> either remove code dependencies on JUEL from Shindig, or modify JUEL
> to break out those dependent implementation classes as some kind of
> external jar separate from the javax.el implementation.
>
> The package that relies on it is org.apache.shindig.expression.
>
> On Fri, Jan 15, 2010 at 10:12 AM, David Boyer <ma...@gmail.com> wrote:
> > It's a legal issue with shipping libs that implement Sun APIs, as I
> > understand it.
> >
> > But you bring up an interesting point that it's use should be isolated
> > to shindig.
> > I'll go back and ask for very specific clarification of the issue.
> >
> > On Thu, Jan 14, 2010 at 3:46 PM, Paul Lindner <li...@inuus.com> wrote:
> >> On Thu, Jan 14, 2010 at 10:19 AM, David Boyer <ma...@gmail.com>
> wrote:
> >>
> >>> We're concerned about JUEL and whether it passes the TCK for JSR-245.
> >>>
> >>>
> >> Why are you concerned? Shindig uses only juel-impl, not juel-api. This
> >> insures that juel in only used for gadget el parsing instead of
> replacing
> >> the el implementation that already exists.
> >>
> >>
> >>> If it doesn't we can't ship it with our Enterprise product. This is a
> >>> big concern to us. The unfortunate part is that shindig uses JUEL
> >>> specific classes and interfaces instead of sticking to the base EL
> >>> interfaces in the Expression Language API, defined by javax.el.
> >>>
> >>> Does anyone know, or can anyone shed any light on this library?
> >>>
> >>> Thanks,
> >>>
> >>>
> >>> --
> >>> David S Boyer
> >>> mangr3n@gmail.com
> >>> 703.499.8728(h)
> >>> 703.408.5395(m)
> >>>
> >>
> >
> >
> >
> > --
> > David S Boyer
> > mangr3n@gmail.com
> > 703.499.8728(h)
> > 703.408.5395(m)
> >
>
>
>
> --
> David S Boyer
> mangr3n@gmail.com
> 703.499.8728(h)
> 703.408.5395(m)
>
Re: JUEL usage
Posted by David Boyer <ma...@gmail.com>.
Question was asked and answered. Juel is in fact an issue for us.
http://juel.sourceforge.net/
We are Java-Certified, we can't ship our products with a library that
doesn't pass a TCK if it implements a JSR. We're going to test this
over the next week or so. I have to track down the TCK and run it
against JUEL, this may not be that simple since the JSR is larger than
just the Expression Language API. My concern is that if it passed
the TCK, the site would most likely state it.
On the shindig side the issue is that shindig uses implementation
specific classes that are not part of the javax.el namespace. So
shindig is tied directly to JUEL, not just the javax.el namespace. If
we can't ship that code, we're going to have to find a way to replace
JUEL with a lib that will pass the TCK. In addition, we would have to
either remove code dependencies on JUEL from Shindig, or modify JUEL
to break out those dependent implementation classes as some kind of
external jar separate from the javax.el implementation.
The package that relies on it is org.apache.shindig.expression.
On Fri, Jan 15, 2010 at 10:12 AM, David Boyer <ma...@gmail.com> wrote:
> It's a legal issue with shipping libs that implement Sun APIs, as I
> understand it.
>
> But you bring up an interesting point that it's use should be isolated
> to shindig.
> I'll go back and ask for very specific clarification of the issue.
>
> On Thu, Jan 14, 2010 at 3:46 PM, Paul Lindner <li...@inuus.com> wrote:
>> On Thu, Jan 14, 2010 at 10:19 AM, David Boyer <ma...@gmail.com> wrote:
>>
>>> We're concerned about JUEL and whether it passes the TCK for JSR-245.
>>>
>>>
>> Why are you concerned? Shindig uses only juel-impl, not juel-api. This
>> insures that juel in only used for gadget el parsing instead of replacing
>> the el implementation that already exists.
>>
>>
>>> If it doesn't we can't ship it with our Enterprise product. This is a
>>> big concern to us. The unfortunate part is that shindig uses JUEL
>>> specific classes and interfaces instead of sticking to the base EL
>>> interfaces in the Expression Language API, defined by javax.el.
>>>
>>> Does anyone know, or can anyone shed any light on this library?
>>>
>>> Thanks,
>>>
>>>
>>> --
>>> David S Boyer
>>> mangr3n@gmail.com
>>> 703.499.8728(h)
>>> 703.408.5395(m)
>>>
>>
>
>
>
> --
> David S Boyer
> mangr3n@gmail.com
> 703.499.8728(h)
> 703.408.5395(m)
>
--
David S Boyer
mangr3n@gmail.com
703.499.8728(h)
703.408.5395(m)
Re: JUEL usage
Posted by David Boyer <ma...@gmail.com>.
It's a legal issue with shipping libs that implement Sun APIs, as I
understand it.
But you bring up an interesting point that it's use should be isolated
to shindig.
I'll go back and ask for very specific clarification of the issue.
On Thu, Jan 14, 2010 at 3:46 PM, Paul Lindner <li...@inuus.com> wrote:
> On Thu, Jan 14, 2010 at 10:19 AM, David Boyer <ma...@gmail.com> wrote:
>
>> We're concerned about JUEL and whether it passes the TCK for JSR-245.
>>
>>
> Why are you concerned? Shindig uses only juel-impl, not juel-api. This
> insures that juel in only used for gadget el parsing instead of replacing
> the el implementation that already exists.
>
>
>> If it doesn't we can't ship it with our Enterprise product. This is a
>> big concern to us. The unfortunate part is that shindig uses JUEL
>> specific classes and interfaces instead of sticking to the base EL
>> interfaces in the Expression Language API, defined by javax.el.
>>
>> Does anyone know, or can anyone shed any light on this library?
>>
>> Thanks,
>>
>>
>> --
>> David S Boyer
>> mangr3n@gmail.com
>> 703.499.8728(h)
>> 703.408.5395(m)
>>
>
--
David S Boyer
mangr3n@gmail.com
703.499.8728(h)
703.408.5395(m)
Re: JUEL usage
Posted by Paul Lindner <li...@inuus.com>.
On Thu, Jan 14, 2010 at 10:19 AM, David Boyer <ma...@gmail.com> wrote:
> We're concerned about JUEL and whether it passes the TCK for JSR-245.
>
>
Why are you concerned? Shindig uses only juel-impl, not juel-api. This
insures that juel in only used for gadget el parsing instead of replacing
the el implementation that already exists.
> If it doesn't we can't ship it with our Enterprise product. This is a
> big concern to us. The unfortunate part is that shindig uses JUEL
> specific classes and interfaces instead of sticking to the base EL
> interfaces in the Expression Language API, defined by javax.el.
>
> Does anyone know, or can anyone shed any light on this library?
>
> Thanks,
>
>
> --
> David S Boyer
> mangr3n@gmail.com
> 703.499.8728(h)
> 703.408.5395(m)
>