- Konstantin
I
totally agree
that we shouldn't remove facets in the service stream, and that's the
first
issue to solve here. Migration/deprecation is also a good topic, and
(if it's
not already documented somewhere) I think the facet framework is on the
hook to
prove that it can be safely done between releases.
However,
Rob
has a valid point here and this is *not* just "shoot the messenger".
The plugin that's defining the JSDT facet isn't going to list every
server that
supports it because that's backwards and it has no idea what servers
may be
provided by third-party adopters. Server adapters can't say that they
support
an optional facet like JSDT either, because if they are ever installed
without
JSDT then the user will get these same "errors" in their log. I'm not
aware of any feasible way to work around this with the current facet
framework,
and we need to fix this.
So
this error
may only indicate that the user's install doesn't include JSDT or some
other
facet, and not an actual problem. Until we can fix facets to only
report real
problems, we should really be removing this error to stop cluttering
user .logs
unnecessarily.
Thanks,
Tim
deBoer
deboer@xxxxxxxxxx
I am somewhat tickled by this
shoot the
messenger mentality. The framework
is telling us that there is a bug in the code and it is telling
us where it
is located so that it can be more easily fixed. I honestly do not
see how
it
would be better to not have known about this problem and shipped
3.0.4 with
a dozen broken extensions referring to a facet that no longer
exist.
Regarding moving these messages to the Eclipse trace facility, I
would
consider that as a misuse of the facility. The error log is for
reporting
problems that plugins run into at runtime, which this case
belongs to. The
trace facility is for providing additional verbose output so that
one can
better understand operation of code under certain conditions. The
Faceted
Project Framework uses both facilities where appropriate.
In all this noise, one important point from my original message
has been
overlooked. Far more serious than the error messages in the log
is that
there are now users out there with JSDT facet referenced in their
project
metadata. Since the JSDT facet was added to the default facets
sets for all
server adapters that are part of WTP, I would venture to guess
that the
install base is quite considerable. When such users upgrade to
3.0.4, they
are going to end up with problem markers on their projects. Even
if the
decision is made that architecturally the JSDT facet is not
necessary, the
cat is out of the bag. The only reasonable course of action is to
reinstate
the facet for 3.0.4 and figure out how to more gracefully phase
it out in
3.1.
Rather than wasting time debating how problems should be
reported, lets
concentrate on fixing the actual problem so that we can have a
solid 3.0.4
release candidate for adopters to test. So far adopting 3.0.4 has
been
rather rough for Oracle products. This is not the only issue we
are
hitting.
More information to come as we test the build more thoroughly.
- Konstantin
-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Rob Stryker
Sent: Wednesday, February 04, 2009 5:27 AM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] JSDT facet gone missing in 3.0.4?
The usecase cited by Konstantin as a reason *not* to remove the
logging is:
> " but the framework can't tell this case from a typo."
If the "typo" case is the only one cited, then the log message is
primarily to be used for debugging during development. In this
case I
believe this should be trace level permanently,
I don't believe "optional" should even be considered, as in all
honesty
if a server supports 100 facets, each and every facet is
optional.
The
server adopter can survive with or without jst.web modules in the
installation, with or without jst.ear modules in the
installation, and
with or without my.custom.deploytype in the installation. How can
we be
sure it can survive? Because if that facet isn't installed, then
that
server adapter will never be asked to deploy it.
Max Rydahl Andersen wrote:
>
>>> In any case, what is 3.0.4 adopters supposed to do
with this
bug ?
>>> Is there anything we can do to fix it ?
>>> We got a release coming up in March and would like
to use
3.0.4 but
>>> want to be sure we don't flood users logs
>>> with these messages.
>> Looking at this again - then if the only thing the facet
framework
is
>> doing is logging that there is a missing thing which
does not
affect
>> any behavior at all shouldn't this be traced instead of
error'd ?
>> I still find it really bad JSDT didn't fix this fully,
but if the
fix
>> would be to lower the logging severity isn't that a
better fix ?
> For reference https://bugs.eclipse.org/bugs/show_bug.cgi?id=251722 is
> the bug we initially raised this issue in.
> Reducing the logging really sounds to me like the least
invasive fix -
> and when the framework once will allow for true optionality
*then*
> hard-error'ing about it would be ok.
>
> Any other suggestions ?
>
> /max
>>
>> /max
>>>
>>> /max
>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Rob Stryker [mailto:rob.stryker@xxxxxxxxxx] Sent: Tuesday,
>>>>> February 03, 2009 8:49 PM
>>>>> To: konstantin.komissarchik@xxxxxxxxxx;
General
discussion of
>>>>> project-wide or architectural issues.
>>>>> Subject: Re: [wtp-dev] JSDT facet gone
missing in
3.0.4?
>>>>>
>>>>> Maybe this is just crazy talk, but perhaps a
server or
runtime type
>>>>> expressing "support" for a facet type should
not cause error messages
>>>>> like this if the facet type is missing. I
know, I
know... I'm
>>>>> living in
>>>>> a dream land... but in my thick empty skull
I kinda
have this notion
>>>>> that "supporting" a facet isn't the same as
requiring it.
>>>>>
>>>>> But, I mean, I could be wrong. Maybe there's
something
in the China
>>>>> water messing with my head. Crazy talk. ...
Crazy.
>>>>>
>>>>> ;)
>>>>>
>>>>> - Rob Stryker
>>>>>
>>>>> Konstantin Komissarchik wrote:
>>>>>> I just double-checked and despite what
is said in
Bug 243183, the
>>>>>> JSDT facet is present in Ganymede SR1
(3.0.2) and
in 3.0.3. It
>>>>>> has been removed in the 3.1 HEAD stream
for a few
months now, but
>>>>>> the change in the maintenance stream has
happened
fairly recently.
>>>>>>
>>>>>>
>>>>>>> surprised by the number of
plugin.xmls that
now have to be
>>>>>>> updated to
>>>>>>> prevent this error message.
>>>>>>>
>>>>>> This was the result of the desire to
have the JSDT
facet on by
>>>>>> default when a user targets one of the
runtimes
that has drivers
>>>>>> shipping with WTP. This meant that this
facet had
to be
>>>>>> explicitly included in all the default
facet sets
for all the
>>>>>> various server types. In my opinion,
this would
have been much
>>>>>> better handled by leaving the facet off
by default
and having
>>>>>> some way to unobtrusively tell the user
that there
is additional
>>>>>> functionality available when the user
goes to
certain contexts.
>>>>>> For instance, if the user opens a
_javascript_ file
or you detect
>>>>>> _javascript_ in an html/jsp, you could put
an
"Enable advance
>>>>>> _javascript_ support" banner link across
the
top of the editor.
>>>>>> That's just my two cents on this.
>>>>>>
>>>>>>
>>>>>>> Even if the facet is added back into
3.0.4,
is/will there be a
>>>>>>> mechanism
>>>>>>> for deprecating or automatically
migrating it
out of 3.1 (by M6
>>>>>>> if that's
>>>>>>> the course of action we decide upon)?
>>>>>>>
>>>>>> That depends on what behavior you are
after. There
is an
>>>>>> enhancement request (Bug 255038) that
was recently
opened that
>>>>>> would allow facets to be marked as
deprecated. In
that case you
>>>>>> leave the facet implementation in the
code base,
but because it
>>>>>> is marked as deprecated it is not
visible on
projects that don't
>>>>>> have it installed already. Project
metadata is not
modified
>>>>>> automatically. Other approaches are
possible as
well, of course.
>>>>>>
>>>>>>
>>>>>> Oracle
>>>>>> Konstantin Komissarchik | Consulting
Member of
Technical Staff
>>>>>> Phone: +1 425 945 8445 | Mobile: +1 206
898 0611
>>>>>> Oracle Eclipse Tooling
>>>>>> 411 108th Ave NE, Suite 800 | Bellevue,
WA 98004
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: wtp-dev-bounces@xxxxxxxxxxx
>>>>>> [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Nitin Dahyabhai
>>>>>> Sent: Tuesday, February 03, 2009 6:17 AM
>>>>>> To: wtp-dev@xxxxxxxxxxx
>>>>>> Subject: Re: [wtp-dev] JSDT facet gone
missing in
3.0.4?
>>>>>>
>>>>>> Looks like it was removed in 3.0.2
through bug
243183, and at least
>>>>>> noticed at the latest from bug 21928,
but not
actually removed
>>>>>> from the
>>>>>> server tools plug-ins. I regret how
poorly
this was handled, and am
>>>>>> surprised by the number of plugin.xmls
that now
have to be
>>>>>> updated to
>>>>>> prevent this error message.
>>>>>>
>>>>>> Even if the facet is added back into
3.0.4,
is/will there be a
>>>>>> mechanism
>>>>>> for deprecating or automatically
migrating it out
of 3.1 (by M6
>>>>>> if that's
>>>>>> the course of action we decide upon)?
>>>>>>
>>>>>> Regards,
>>>>>> ---
>>>>>> Nitin Dahyabhai
>>>>>> Eclipse WTP Source Editing
>>>>>> IBM Rational
>>>>>>
>>>>>>
_______________________________________________
>>>>>> wtp-dev mailing list
>>>>>> wtp-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>>>>>
>>>>>>
_______________________________________________
>>>>>> wtp-dev mailing list
>>>>>> wtp-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> wtp-dev mailing list
>>>> wtp-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>>
>>> _______________________________________________
>>> wtp-dev mailing list
>>> wtp-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>
>> _______________________________________________
>> wtp-dev mailing list
>> wtp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev