This question already has an answer here:
File names for JSP include directive to avoid compilation of them
(1 answer)
Closed 5 years ago.
What are .jspf files in JSP? As I know the compiler will look for .jsp files to compile, then how are the .jspf files compiled?
As others have noted, .jspf files are JSP fragments. They're designed to be statically included in another JSP file, not compiled on their own:
<%#include file="/WEB-INF/jspf/example.jspf" %>
You'll note that this example comes from the /WEB-INF/jspf directory. This means that it is not accessible outside of the web application; there's no way to construct a URL that can retrieve it. If you put them in the same directory as "normal" JSP files, you can construct such a URL; Tomcat, for example will retrieve the page as a text document. A front-end web-server, however, can block these URLS.
I like JSPF files as a first step in refactoring large JSP pages. Since they're statically included, you can extract a small chunk of the file without making provision for scriptets or variables, leading to pages that are somewhat more maintainable (and I want to stress, it's a first step; dynamic includes and taglibs are usually a better long-term solution). When refactoring, I believe in keeping the fragments close to their parent files; this is when having a web-server to block URLs becomes useful.
JSP Fragments can be compared to server side includes. These fragments are not compiled on their own, however there are compiled along side the page in which its included. If I've to display different pages base on a user preference, i will opt for jspf.
What : .jspf files are generally files that are included in .jsp files via the include directive. The 'f' stands for 'fragment' as these files are not full JSPs in and of themselves.
How to Compile: Since .jspf is a fragment of a jsp hence it may not be complete and compilable source, so most of the time it can't be compiled independently of another, complete, source that references them.
Source : Ibm Infocentre
IBM says that .jspf is for JSP fragments. A fragment may not be complete and compilable source, so they likely can't be compiled independently of another, complete, source that references them.
They're mentioned in Sun's developer resources in the same context - a naming convention for JSP Fragments.
In many web frameworks, it's possible to assemble views and pages from smaller, shared views and pages. Using JSP, these smaller pieces are called fragments. As the name implies, they're not necessarily a complete representation without some larger context.
Other languages and frameworks have their own term for the equivalent concept. In Ruby on Rails, for example, they're called partials.
Related
I have a web application that contains hundreds of HTML, JavaScript and image files. These files are located under the root directory:
my_root--
-- html
-- js
-- images
These folders contain some subfolders.
From a security reason I need to move all these resources under the WEB-INF folder so they will not be directly accessible.
Currently JSP and servlet files are already under the WEB-INF folder.
What is the easiest method for me to safely move all HTML/JavaScript/images folders under the WEB-INF without breaking all links/forwarding to resources in these folders and make sure these resources are not directly accessible?
I am using WebSphere and WebLogic servers.
What is the easiest method for me to safely move all html/js/images folders under the WEB-INF without breaking all links/forwarding to resources in these folders and make sure these resources are not directly accessible?
You're making a thiniking mistake here. HTML/JS/image (and CSS) resources need to be directly accessible anyway. For JSPs the story is different, some of them, if not all, need to be preprocessed by a servlet (e.g. to retrieve some list from DB for display in a table). If those JSPs were been accessed directly, then that servlet step would be skipped altogether, which is absolutely not what you want (the JSPs end up "empty"; without any data from the DB). That's why they should be hidden in /WEB-INF to prevent direct access without going through a preprocessing servlet first. Also, in case of servlet based MVC frameworks, this way the whole MVC framework process (collecting request parameters, converting/validating them, updating model values, invoking actions, etc) would be skipped.
Your concrete functional requirement is not exactly clear (the whole question makes at its own no sense; the answer is just "don't do that"), but if you actually want to restrict access to static resources which don't need to be preprocessed by a servlet at all to certain users only, then you need to implement an authentication/login system. You can utilize container managed authentication or homegrow a Filter for this.
You can go with a very simple tool like notepad++ and use the findAndReplace feature. Eclipse can also do this but it gets tricky to effectively find every reference.
Note that there are other ways to stop users from accessing your images. It is probably easier to just leave things where they are and instruct the websphere to stop serving these images from the images folder
JSP page in its lifecycle translated into .java file, but is JSP page itself a java class?
Confused and need help.
JSPs are compiled into Java Servlets, and Java servlets are classes. So yes, the JSP is compiled to a Java class. The name is usually automatically generated, and is visible in any stack traces (if you throw an Exception).
From here:
A JavaServer Pages compiler is a program that parses JSPs, and transforms them into executable Java Servlets.
And from here:
Java Servlet technology provides Web developers with a simple, consistent mechanism for extending the functionality of a Web server and for accessing existing business systems. Servlets are server-side Java EE components that generate responses (typically HTML pages) to requests (typically HTTP requests) from clients. A servlet can almost be thought of as an applet that runs on the server side
Since applets are classes, hence, a JSP is a class.
The intend behind JSP is Actually makes easier for JAVA developer + front end Developer to
write not only Java code also need to write HTML code and other which
is easily stuff with html code too for full fill the task complete.
so, let's say, my jsp page is home.jsp, then it's translating from .jsp to .java by home_jsp.java which will enclosed all non-java code into java.
and finally home_jsp.class file generate which will run on JVM.
JSP page life cycle and many of the capabilities of JSP pages (in
particular the dynamic aspects) are determined by Java Servlet
technology.
Now, i hope you are little bit clear on your query that was,
JSP page in its lifecycle translated into .java file, but is JSP page itself a java class?
Best of luck...!!!
A JSP pages compiler is a program that parses JSPs, and transforms them into executable Java Servlets and that java Servlets is a simple java class.
I am developing an application using Java and Spring MVC. As usual, stored one JSP file in /WEB-INF/view/ folder which is working as the View for all the requests.
Normally we have this JSP hard-coded that also has some codes to process the Model (tags and EL). Things are working fine till this point.
Now instead of hard-coding the JSP, I want to populate this JSP file dynamically from the database. So the user can upload and select different templates/themes/layouts to display his pages.
Here is the code to explain what I am trying to do (I know this is not the way but for illustration purpose only).
/WEB-INF/views/index.jsp
<%# page import="com.example.domain.Template" %>
<%# page import="com.example.dao.TemplateStore" %>
<!-- Following code is supposed to return complete JSP template from the database as uploaded by the user. -->
<%= TemplateStore.getUserTemplate("userTemplate") %>
I searched web for this topic but could not find anything.
Any help on how to accomplish this would be highly appreciated.
Thanks in advance.
IMPORTANT: I have asked this question a few days ago but marked as "off-the-topic" by some members. I am yet to understand how this question is off-the-topic - https://stackoverflow.com/questions/18026092/creating-content-of-jsp-views-in-web-inf-views-dynamically-from-the-database.
If view templates are to be dynamically fetched from a database, you shouldn't think of JSP. JSPs are compiled into servlet classes and there's little support for doing that other than the standard way (static files somewhere under your webapp root).
Therefore, just consider switching the view technology (at least for the dynamic part) to some general-purpose templating library like Velocity or Freemarker. This comes with a security bonus, since there's less one can break from within such a template than from within JSP code.
You could even support multiple view technologies (perhaps anything that Spring MVC supports out-of-the-box, except for JSP) and allow your users to choose the type of template when uploading.
Then you can write a custom view resolver which would delegate to the appropriate standard resolver (Velocity, Freemarker, XSLT, whatever...) with the user-selected template.
However, if JSP is a hard requirement, I guess one ugly workaround for JSP (which should work in any servlet container) could be to fetch content from the DB and create an actual file (like WEB-INF/templates/${primarky-key}.jsp) under your exploded webapp root, then RequestDispatcher.forward() to it.
You might or might not be able to do this with JSP, but you can certainly compile Java code in memory and then call it.
http://www.java2s.com/Code/Java/JDK-6/CompilingfromMemory.htm
Of course going from JSP to Servlet would just be another step.
For GWT we use static constants to provide internationalization for our users. However, this makes reviewing and editing the texts a tedious process, because if one of our stakeholders has comments, it has to be compiled and deployed to our demo environment again. The solution would be to have some kind of semi dynamic text constants.
What I would like, is that I can compile to some kind of "review mode", and when I do that, the constants are read from a file from the server or database. If possible I would like to be able to edit this file, so stakeholders can modify the texts themselves (using some kind of text edit widget I would have to write for that). Then we can develop, test and demo with these texts. If we are satisfied, we compile for production mode, which uses a old fashioned constants resource bundle, compiled completely in JavaScript.
Does somebody know if something like this exists, or have some pointers on how to implement this?
It is a very surprising situation that GWT programmers often overlook the usefulness of JSPs and the Dictionary class. Even though many of us had tons of JSP experience prior to using GWT.
Dictionary class
You can define your "static" information as javascript var objects in the html hosting file. The Dictionary class can be used to read those javascript objects any time after moduleload.
JSP
The HTML "hosting" file, i.e. the html file used for launching GWT need not be an HTML file. It can be a HTML file dynamically generated by a JSP.
If you are familiar with JSP, you could turn an HTML file into a JSP just by changing its extension. Now turn the javascript object section you used for defining GWT "static" information into being dynamically generated by the JSP.
Voila!
I use JSP as the hosting file when I need to generate user- or session- specific "static" information for the GWT client. The JSP could read from the database or from some conditionally chosen text files.
I am continuing my practices with JSF 2.0.
I see templating is a great thing to do, and it has lots of advantages. But today i got a new doubt related to it.
I created a template for my pages.
In the template, i use tags for the parts that are different(Those parts will be implemented later in a page using the composition tag in combination one or more define tags).
<ui:insert name="content" />
Also inside the template, to avoid putting to much code in the template, i create tags to add some other chunks of xhtml.
<ui:include src="/languageChanger.xhtml"/>
This is how my folder structure looks:
It all works as i spect, but when in the url i navigate to languageChanger.xhtml i see the composite chunk of xhtml:
My doubts are:
-Is that chunk of independent code placed in the right place?, Or it is wrong, the user should not be allowed to see that from the URL?
-Is that place save to have other components like login, register...?
-To avoid user access directly the component i could place it in WEB-INF folder, but then i have a problem that the include tag does not find the path. What should i do?
-What would be the best practice, where to place this independent chunks of code?
Is that chunk of independent code placed in the right place?, Or it is wrong, the user should not be allowed to see that from the URL?
Put it somewhere in /WEB-INF. Direct access to this folder is disallowed by the container.
Is that place save to have other components like login, register...?
I don't understand you. Perhaps you meant to say "safe" instead of "save"? What do you mean with "other components"?
To avoid user access directly the component i could place it in WEB-INF folder, but then i have a problem that the include tag does not find the path. What should i do?
Your path was apparently plain wrong. Facelet templates, includes, tags and compositions (not composite components) can perfectly be placed in /WEB-INF.
What would be the best practice, where to place this independent chunks of code?
Put it in /WEB-INF. Best practice is to use absolute paths, i.e. start the path with /. It will be resolved relative to the webcontent root. E.g.
<ui:include src="/WEB-INF/languageChanger.xhtml" />
Only the "main" page (the one which is to be requested by URL) cannot be placed in /WEB-INF.
For your first two questions:
Is that chunk of independent code placed in the right place?, Or it is wrong, the user should not be allowed to see that from the URL?
Is that place save to have other components like login, register...?
The templates and the default content used by them are in the right place. They must be present under the web application's document root, and not elsewhere.
For your last two questions:
To avoid user access directly the component i could place it in
WEB-INF folder, but then i have a problem that the include tag does
not find the path. What should i do?
What would be the best practice, where to place this independent
chunks of code?
The partial answer is provided above, where the need to place included files under the document root has been mentioned. The "resource resolver" used by the JSF runtime, requires that the facelet be present under the document root of the application. Facelets cannot be placed in WEB-INF for this reason.
If you need to prevent users from accessing these pages directly, then you must write a web-application filter to prevent access to these pages.
The Mojarra runtime does not internally forward any HTTP requests to a template resource; instead, it includes the contents of the file, retrieved as a stream. This implies that you need not restrict the filter to dispatch types of REQUEST alone; you can apply the filter to all dispatch types.
Placing all templates and the included facelets, in a /templates directory would make it easier to apply the filter on a single URL - /templates/*.