You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Definition of Liskov's principle: If S is a subtype of T, then we can replace T by S and all the properties are still true.
I dunno if it's a desired feature or a unfortunate side-effect.
If we consider those two classes:
class A {
@WebMethod(name = "fromA")
public void entryPoint(){...}
}
and
class B extends A {
@Override
@WebMethod(name = "fromB")
public void entryPoint(){...}
}
and they are both "gettable" from the root object.
My initial expectation was to have valid URLs: /a/fromA/, /b/fromB/ and /b/fromA/. But actually the last one is not considered.
We can consider it's the expected behavior, meaning you have full control on your class. As you can provide multiple name in the annotation, there is no problem.
Problem, in case the class A comes from a third party and they add a new name, as a library user you are not notified about that change and your class B will not be Liskov-compliant.
Imagine you have an endpoint that propose a list of A. But inside that list, one element is a B. If you consider reaching the URL: /list/0/fromA/, if you fall on the B element, you get a 404 while a normal response was expected.
As an alternative to keep the full control, we can process the annotation of all the parent classes and add a new annotation that explicitely tells Stapler
either we want to remove one name from parents (to have possibility to rename URL)
or avoid completely going further in the hierarchy (to avoid undesired third-party change)
The text was updated successfully, but these errors were encountered:
Definition of Liskov's principle: If
S
is a subtype ofT
, then we can replaceT
byS
and all the properties are stilltrue
.I dunno if it's a desired feature or a unfortunate side-effect.
If we consider those two classes:
and
and they are both "gettable" from the root object.
My initial expectation was to have valid URLs:
/a/fromA/
,/b/fromB/
and/b/fromA/
. But actually the last one is not considered.class A
comes from a third party and they add a new name, as a library user you are not notified about that change and yourclass B
will not be Liskov-compliant.A
. But inside that list, one element is aB
. If you consider reaching the URL: /list/0/fromA/, if you fall on theB
element, you get a 404 while a normal response was expected.The text was updated successfully, but these errors were encountered: