Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] Enablement expression support in validator ext point


Why would this deprecation message ever have to be part of the log that is sent to support? Its not doing them, or the user, any good.

Tim has given one example, and, I, as another battled-scared committer of this mistake, have had "real life" experience  ... I did something similar once, and probably got 5 or 10 "official" support phone calls about "what does this warning mean", my customer is wondering if its related to the bug they are having (and while obvious to developers it wasn't related ... it is not so obvious to support people or customers) ... and I must have gotten 20 similar calls from "add on" providers -- so, I think the cost of confusion outweighs the benefits.

So, I don't see it as "theoretical" ... There's better mechanisms for both deprecations warnings and for plugin developer aides. Let's use them.

And .. careful .. if you have strong views on logging, I am looking for someone to own the logging strategy for WTP :)








"Konstantin Komissarchik" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/17/2006 06:56 PM

Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>

To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
RE: [wtp-dev] Enablement _expression_ support in validator ext point





I disagree. PDE error log is not an end-user tool. It’s meant to help plugin authors identify problems that occur at runtime. As in support directing the customer to send the error log to them for trouble shooting. Your average user should not have any need to look at the log (it’s hidden by default). If they do, that just means that we are not doing our jobs.
 
Regarding the particular question of using the log to report deprecation warnings, I believe that this is not inconsistent with what the PDE error log is supposed to be used for and is the best tool we have for making sure that usage of deprecated functionality does not go unnoticed by the plugin owner. Everyone is happier when there are fewer surprises as the deprecated functionality is removed in the next release. I also don’t agree that this hides real errors as there is very good visual separation between warnings and errors and deprecation reporting only needs to produce one message per extension point / plugin combination (not a lot).
 
- Konstantin
 
 



From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent:
Monday, April 17, 2006 3:38 PM
To:
General discussion of project-wide or architectural issues.
Subject:
RE: [wtp-dev] Enablement _expression_ support in validator ext point

 

I agree with Tim. We should only log things we think users/consumers should see ... otherwise, please "hide" unless turned  on with some explicit  -debug .facet-options flag.
(and, encourage *developers* to clean up their warnings, and/or turn on deprecated extension points to the 'error' level -- PDE i s your friend :)  




Timothy Deboer <deboer@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/17/2006 04:00 PM


Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>


To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
 
Subject
RE: [wtp-dev] Enablement _expression_ support in validator ext point

 


   






Hi,


While I agree that a little incentive helps to move people off deprecated API, deprecated Java code doesn't produce output at runtime and I'm not sure that extension points should. Throwing everything out to the .log hides real errors and can produce a lot of extraneous output. When the similar change was made in facets I received several email from panicked users who thought WTP was failing or blamed other problems on the errors in the log.


Thanks,

Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503  (tieline 969)
deboer@xxxxxxxxxx

"Konstantin Komissarchik" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

17/04/2006 02:14 PM


Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>


To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
<wtp-dev-bounces@xxxxxxxxxxx>
Subject
RE: [wtp-dev] Enablement _expression_ support in validator ext point

 


   






Vijay,


You may want to consider logging deprecation warnings into PDE Error Log when the deprecated extension syntax is detected. The deprecation warning should include the id of the plugin that the deprecated syntax is used in. This way the plugin owner is more likely to become aware that they are using deprecated syntax and will transition to the new syntax more quickly.


I have done this for all the syntax that I have deprecated in the faceted project framework.


- Konstantin

 

 




From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Vijay Bhadriraju
Sent:
Monday, April 17, 2006 11:07 AM
To:
General discussion of project-wide or architectural issues.
Cc:
General discussion of project-wide or architectural issues.; wtp-dev-bounces@xxxxxxxxxxx
Subject:
Re: [wtp-dev] Enablement _expression_ support in validator ext point



Yes, enablement is the recommended way to filter validators based on facets, the facet filters has been deprecated but will continue to work.


Regards, Vijay
_____________________________
Vijay Bhadriraju
Rational Tools, J2EE Tooling
Ph: (919) 486-1898, T/L: 526-1898
Internet: vbhadrir@xxxxxxxxxx

_____________________________

Lawrence Mandel <lmandel@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/17/2006 12:10 PM

 


Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>

 


To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
 
Subject
Re: [wtp-dev] Enablement _expression_ support in validator ext point



 

 


   







Hi Vijay,


Is the enablement method now the recommended way to restrict based on facets? Has the facet filters support been deprecated?


Thanks,


Lawrence Mandel

Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814   Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx

Vijay Bhadriraju <vbhadrir@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/16/2006 10:52 PM

 


Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>

 


To
wtp-dev@xxxxxxxxxxx
cc
 
Subject
[wtp-dev] Enablement _expression_ support in validator ext point



 

 


   








The support for enablement _expression_ as shown below has been added to the validator extension point. The facet filters support added in the validator ext point in addition to natures  did not scale very well and additional requirements from some extended teams drove the need for the enablement support which scales very well.  This _expression_ support covers all the combinations that the
FacetedProjectPropertyTester provides as this is the tester class that is used under the covers for property and value strings.

The ejb validator is changed to use this support instead of facet filters


<extension

   
id="EJBValidator"
   
name="%EJB_VALIDATOR"
   
point="org.eclipse.wst.validation.validator">
 
<validator>
   
<enablement>
           
<and>
                   
<test property="org.eclipse.wst.common.project.facet.core.projectFacet" value="jst.java"/>
                     
<test property="org.eclipse.wst.common.project.facet.core.projectFacet" value="jst.ejb"/>
             
</and>
     
</enablement>
   
<filter
         
objectClass="org.eclipse.core.resources.IFile"
         
nameFilter="ejb-jar.xml">
   
</filter>
   
<filter
         
objectClass="org.eclipse.core.resources.IFile"
         
nameFilter="*.class">
   
</filter>
   
<filter
         
objectClass="org.eclipse.core.resources.IFile"
         
nameFilter="*.java">
   
</filter>
   
<helper
         
class="org.eclipse.jst.j2ee.internal.ejb.workbench.validation.EJBHelper">
   
</helper>
   
<dependentValidator
         
depValValue="true">
   
</dependentValidator>
   
<markerId
         
markerIdValue="EJBValidatorMarker">
   
</markerId>
   
<run
         
class="org.eclipse.jst.j2ee.internal.ejb.workbench.validation.UIEjbValidator">
   
</run>
 
</validator>
</extension>


The facet filters support still exists and works in the validator ext point even though it is redundant with this enablement support. The reason it is still supported is for the fact that we are not supposed to break any internal api also at this point for 1.5. Validators using facet filters will continue to work as is and the any validators that need the enablement _expression_ support can migrate.


Regards, Vijay
_____________________________
Vijay Bhadriraju
Rational Tools, J2EE Tooling
Ph: (919) 486-1898, T/L: 526-1898
Internet: vbhadrir@xxxxxxxxxx

_____________________________
_______________________________________________
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

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

_______________________________________________
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

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev


Back to the top