@kendalls5216292 Disclaimer :- ✌😊 I am not a SLING expert . But still I would like to point out few things I know . As much as I know.
Lets take your question one by one
if I look at /libs/foundation/components/parsys there is a child node parsys.jsp.
Does any jsp file get executed? - Yes , it does. Much before the entire stack was changed to HTL, we were that old guys with a lot of JSPs. So a lot of components in the /libs/foundation/components still uses JSPs for rendering . Why ? for backward compatibility (I think that's the right word 🙄). There might be a lot of legacy projects still running on them , or quite a few projects in which they might not have completely migrated ut still using some of these components. So yes , these JSPs execute.
Or what declares that that jsp file should be executed? - To exactly answer that one , you have to go through the sling resolution . A better start would be https://issues.apache.org/jira/browse/SLING-387 here. It exactly defines how sling resolves a component. So when you hit a content node in the browser , lets say /content/we-retail/en/us/home.html , the first thing which sling looks for to execute and deliver your content is a property called sling:resourceType under your home node. This resourceType in 90% scenarios will be pointing to a cq:Component in your repository. Now as for any rendering logic, Sling also need to define a rendering logic for its components. And that what its main Job is to. So, as per its definition and sling resolution principles , the JSP gets executed in the order it should be.
You asked about properties of node types and about execution of JSPs. This leaves me a bit confused because the two things are not really related 🤔 I think @Veena_Vikram gave you a good answer about JSPs and sling resolution, here is my answer about node type properties.
Defines a CQ component.
@prop jcr:title- Title for the component.
@prop jcr:description- Description of the component.
@node dialog- Primary dialog.
@prop dialogPath- Primary dialog path (alternative to dialog).
@node design_dialog- Design dialog.
@prop cq:cellName- Name of the design cell.
@prop cq:isContainer- Indicates whether this is a container component. This forces the cell names of child components to be used instead of path names. For example, theparsysis a container component. If this value is not defined, the check is made based on the existence of acq:childEditConfig.
@prop cq:noDecoration- If true, no decorationdivtags are drawn when including this component.
@node cq:editConfig- The configuration that defines the parameters for the edit bar.
@node cq:childEditConfig- The edit configuration that is inherited by child components.
@node cq:htmlTag- Defines additional tag attributes that are added to the "surrounding"divtag when the component is included.
@node icon.png- A file that holds a characteristic icon.
@node thumbnail.png- A file that holds a characteristic thumbnail image.
@prop allowedParents- Regular expression patterns to determine the path(s) of components that are allowed as parent components.
@prop allowedChildren- Regular expression patterns to determine the path(s) of components that are allowed as child components.
@node virtual- Contains subnodes that reflect virtual components used for the component drag and drop.
@prop componentGroup- Name of the component group, used for the component drag and drop.
@node cq:infoProviders- Contains subnodes, each of which has a propertyclassNamethat refers to aPageInfoProvider.
That is from this page, which lists the OOTB node properties used in AEM (many of which come from CQ5, AEM predecessor). Hope this helps! 🙂