This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes JSP and the fly likes jsp-config does not appear to be Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » JSP
Bookmark "jsp-config does not appear to be "shared"" Watch "jsp-config does not appear to be "shared"" New topic
Author

jsp-config does not appear to be "shared"

Erron Austin
Greenhorn

Joined: May 01, 2007
Posts: 9
I have Front-Controller Servlet that fowards all requests to jsp's located outside the application war. So, for example, http://localhost/myapp/test.jsp is actually a jsp located at (on windows) c:/content/client1/pages/test.jsp.

The issue is that I have the following in my web.xml:
...
<servlet>
<servlet-name>FrontServletController</servlet-name>
<servlet-class>com.diginsite.product.webcenter.website.FileController</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>FrontServletController</servlet-name>
<url-pattern>*.jsp</url-pattern>
</servlet-mapping>
<jsp-config>
<jsp-property-group>
<url-pattern>*.jsp</url-pattern>
<scripting-invalid>true</scripting-invalid>
</jsp-property-group>
</jsp-config>
...

However, the c:/content/client1/pages/test.jsp file does contain a scriptlet and it is working fine. Removing the FrontServletController and accessing a jsp containing a scriptlet within the webapp results in the desired error. I've also attempted changing the url pattern of the jsp-property-group directly to /*/*/*/test.jsp with no luck as well as changing the url-pattern of the servlet to *.myext.

Using Tomcat 5.5.17.

Any other ideas? Any changes I should be making to server.xml?

Thank you
[ May 01, 2007: Message edited by: Erron Austin ]
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61084
    
  66

You seem to have omitted to state exactly what the problem is.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Erron Austin
Greenhorn

Joined: May 01, 2007
Posts: 9
Sorry I wasn't clear.

The problem is the c:/content/client1/pages/test.jsp contains a scriptlet. Therefore, it should display an error. But it renders correctly.

So, is there way for me to guarantee that all jsps (even those outside the war) DO NOT contain any scriptlets?
[ May 01, 2007: Message edited by: Erron Austin ]
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61084
    
  66

How exactly are you fowarding to JSPs outside the web app?
Erron Austin
Greenhorn

Joined: May 01, 2007
Posts: 9
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61084
    
  66

Ah, so the JSPs in question are loaded as part of another web app contenxt. You should have said so.

To tell you the truth, under these conditions I'm not sure what the expected behavior should be. Should the JSPs operate under the rules of the calling web app, or the web app within they have been loaded? Personally, I'd never structure a web app like this -- I'd perform the sharing at build time (rather than at run time) and copy the required JSPs into a single application thus avoiding any cross-context problems.

You may have to do some digging into the JSP Spec to find out what should be happening.
Erron Austin
Greenhorn

Joined: May 01, 2007
Posts: 9
Just to clarify, this is not calling another web app. The purpose of calling the other context (and there will probably be a least 3 more if this issue can be solved) is to allow the content (jsp files) to live in different locations. The web-app is to be used in ASP environment where new clients are added almost daily but the web-app can only be deployed during certain cycles, and thus the jsps can not live in the web-app.

So my high level plan was to have a proxy sit in front of the web-app. The proxy will set headers to identify the client. The web-app will use that header to serve up the correct jsp.

Perhaps there is a better way to structure the app. I welcome any suggestions since we are still at just the prototyping phase.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61084
    
  66

Originally posted by Erron Austin:
Just to clarify, this is not calling another web app. The purpose of calling the other context ...


Another context is another web app. That's like saying "My dog isn't on the neighbors lawn, he's next door".

new clients are added almost daily but the web-app can only be deployed during certain cycles, and thus the jsps can not live in the web-app.


Disconnect. Why do "new clients" == "new JSPs"? That's not a given. What is it about your situation that demands new pages for new clients? We add dozens of new clients daily to our system without the need for new pages.

And, JSPs can be dynamically added to a web app without a restart. Of course if you are following accepted practices those JSPs will have controllers that cannot be, so that point may be moot.
[ May 01, 2007: Message edited by: Bear Bibeault ]
Erron Austin
Greenhorn

Joined: May 01, 2007
Posts: 9
By saying I was calling another web-app, I meant that were I call

this in not pointing to a deployed live.war. I simply added
to my $TOMCAT_HOME/conf/server.xml. By the way, I'm not seeing any extra logging here.

New Clients = New JSPs because each client will have their own highly customized website.
So, <a href="http://www.client<i rel="nofollow">1</i>.com/home.jsp" target="_blank">http://www.client1.com/home.jsp will need to actually point to c:/content/client1/pages/home.jsp
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61084
    
  66

Originally posted by Erron Austin:
this in not pointing to a deployed live.war. I simply added ...


Makes no difference if it's packaged as a war or not. Each context is its own web app. Stating otherwise will just be confusing.

New Clients = New JSPs because each client will have their own highly customized website.


I see, and I assume customized to the point where clever use of CSS and JSP won't help? Our app is heavily branded and intensively role-based. Between CSS and applying role-based rules to who can do what, we give each client what they want through a single set of pages.

If your app diverges enough per client to warrant completely new sets of pages, that may nt be an option for you.

If you're going to give each client their own web app to being with, why not simply reverse what I suggested at first: create a single web app for each client, sharing the core functionality at build time? Spreading the functionality across a "core" web app with cross-context requests to "client" web apps isn't buying you anything except headaches and one extra web app loaded on your system.
Erron Austin
Greenhorn

Joined: May 01, 2007
Posts: 9
Makes no difference if it's packaged as a war or not. Each context is its own web app. Stating otherwise will just be confusing.


Good point, agreed.

Our system admins are against deploying seperate web apps per client.

I will investigate workarounds for a little while longer, but I may have to resort to using a templating framework, unless someone can recommend a jsp based framework that can fit my needs.

Thanks for your help!!
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61084
    
  66

Originally posted by Erron Austin:
Our system admins are against deploying seperate web apps per client.


You already are. What I'm suggesting reduces the number of weeb apps being deployed by one.

but I may have to resort to using a templating framework,


What's that going to do for you that the one you are using now, namely JSP, can't do?
[ May 01, 2007: Message edited by: Bear Bibeault ]
Erron Austin
Greenhorn

Joined: May 01, 2007
Posts: 9
Well, the only problem that I have right now is that I can't prevent scriptlets in the jsp. However, due to our security restraints, this is a showstopper. With a templating framework, like Freemaker, scriptlets will not be an issue.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61084
    
  66

My solution covers this. By avoiding cross-context requests, you shouldn't run into any problems with cross-context weirdness.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61084
    
  66

P.S. If the only difference between your client apps is JSP pages -- that is, if the servlet controllers are shared, you should be golden with a single app as JSPs can be "hot deployed". There's no reason to be placing them in another context to begin with.
 
Consider Paul's rocket mass heater.
 
subject: jsp-config does not appear to be "shared"