Erron Austin

Hi Paul,

Do you have any insights into which topic causes test takers the most problems?  Also, do you have a study guide that accompanies the practice questions?

Thanks!

Are development environments accessible today? Are there any free/low-cost ones that would allow hobby and/or educational development?

In your preface you mention that Java has grown in size and complexity, do you think that this was inevitable and just requires developers to be more disciplined in their use of the language in order for it to be used in practical, effective manner or do you think that the "guardians" of the platform should be doing something to keep/reduce the current complexity while keeping it relevant in relation to other platforms or even other JVM languages like Kotlin?

I'm a Java Developer looking to move into mobile development. From your reply, would you recommend I start off with just working with Kotlin?

Does the book cover writing applications in Kotlin? Are there advantages to creating Android apps in Java rather than Kotlin or vice versa?

I've seen a lot of UI frameworks starting to push unit testing down to the UI layer.

Do you have recommendations about how best to unit test UI code, e.g. GWT, Vaadin, Javascript frameworks?
In our opinion, does testing the UI logic make sense for this layer or should you focus on E2E testing with tools like Selenium?

Thanks,

Hi,

The liferay portal is filled with JSPs that use Scriptlets, and at times, it appears that updating the exploded war in JBoss doesn't always result in seeing the change you are expecting. It requires and re-compile and redeployment of the application.

So,

1. Have you had any clients using the your product with Liferay?
2. Do you think using JRebel would be more reliable than the method of just copying over the updated JSP?
3. Do JRebel having any issues with static classes/methods?

Thanks,

Erron Austin

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.

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!!

By saying I was calling another web-app, I meant that were I call
getServletContext().getContext("/live");
this in not pointing to a deployed live.war. I simply added
<Context path="/live" docBase="c:/" debug="9" crossContext="true"/> 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

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.

String page = "content/client1/pages/test.jsp"; ServletContext otherContext = getServletContext().getContext("/live"); RequestDispatcher dispatch = otherContext.getRequestDispatcher(page); dispatch.forward(request, response);

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 ]

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 ]