struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zahid Rahman <zahidr1...@gmail.com>
Subject Re: convention plugin Issue
Date Thu, 19 Dec 2019 06:52:47 GMT
This is not overriding method.

<action name="hello"
class="org.apache.struts.helloworld.action.HelloWorldAction"
method="execute">

As you see when you declare the same functionality using the
struts.xml Then only that explicitly declared
method will be executed by the struts API [framework] in the
explicitly declared package.class.

Overriding methods in OOP means not using certain declared methods
from inherited classes and super impose on inherited methods by
writing your own methods.
So you use some methods from the inherited class not all [Pick and
choose, adapt]

This is randomly picking up a class by matching the  class names only.
There is no way to match packages names same as stuts.xml due to design of
annotation API. So I am suggesting do a match of same class names  [
validation  method in the annotations API ]  and raising an error to the
application developer of presence of duplicate class names.





On Thu, 19 Dec 2019 at 05:59, John Bush <jtbush@mchsi.com> wrote:

> Overriding methods *is **a valid feature* in Java and probably all
> object oriented languages. I'm confident, even at that lowest level, you
> wouldn't be able to avoid methods being overridden. Above those layers
> of code you have many more layers of code to provide the ability to
> communicate with and over web technologies. Again with a high
> probability of more methods being overridden. Eventually you get to the
> Struts framework which is not flat. It is again layers of code, with
> again a high probability of more methods being overridden.
>
> IMHO A developer needs to understand the technology stack used including
> the order of classpaths searched at execution time. A framework is
> intended to help you do a job which implies you know what it's doing.
>
> John
>
> On 12/18/2019 9:48 AM, Lukasz Lenart wrote:
> > Feel free to register a ticket in JIRA, but this is something low
> > priority rather.
> >
> >
> > Regards
> > Lukasz
> >
> > sob., 7 gru 2019 o 12:58 Zahid Rahman <zahidr1000@gmail.com> napisaƂ(a):
> >> I think the convention plugin should perform a validation a check for
> the
> >> presence of multiple same class names within different
> >> package names. That ambiguity has been shown by my test.
> >> After all it is quite feasible and likely that we could have multiple
> same
> >> class names from different package names
> >> from jars which have been placed on the classpath.
> >> We cant have the convention plugin randomly (as shown by my test)
> >> executing random code.
> >>
> >> On Sat, 7 Dec 2019 at 10:51, Yasser Zamani <yasserzamani@apache.org>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> I guess that the behavior of defining actions with same name and
> namespace
> >>> is undefined. I think it's not an issue because Convention Plugin has
> no
> >>> avenue to distinguish between them when you request
> >>> http://localhost:8080/hello-world.
> >>>
> >>> Regards.
> >>>
> >>>> -----Original Message-----
> >>>> From: Zahid Rahman <zahidr1000@gmail.com>
> >>>> Sent: Thursday, December 5, 2019 4:51 PM
> >>>> To: Struts Users Mailing List <user@struts.apache.org>
> >>>> Subject: convention plugin Issue
> >>>>
> >>>> Hi,
> >>>>
> >>>> On this page
> >>>> https://struts.apache.org/plugins/convention/#setup
> >>>>
> >>>> if I have  com.example.actions.HelloWorld.java
> >>>> and
> >>>> uk.mypackage.actions.HelloWorld.java
> >>>> with  url http://localhost:8080/hello-world then
> >>>> uk.mypackage.actions.HelloWorld.java  execute is run.
> >>>>
> >>>> If I have
> >>>> uk.example.actions.HelloWorld.java
> >>>> and
> >>>> com.example.actions.HelloWorld.java
> >>>> then  com.example.actions.HelloWorld.java  execute is run.
> >>>>
> >>>> uk.mypackage.actions.HelloWorld,java overrides the other two.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message