Updating JSP causes Workspace to auto rebuild.. causing Tomcat to restart :(
Updating JSP causes Workspace to auto rebuild.. causing Tomcat to restart :( I'm now turning off auto build when working in jsp's, obviously forgetting to switch it on when doing java class changes Any other way this can be solved? Jacob Willig ING Bank Europe Web Team OPS&IT/ADC GS/AM COSS/EWT (ex-OPS&IT/SIS/DEV/EWT) Technical Specialist, Web Applications Location Code CT 01.12 Hoogoorddreef 60 P.O.Box 1800, 1000 BV Amsterdam, The Netherlands P +31 20 57 67152, F +31 20 5767280, M + 31 6 538 66 112 E [EMAIL PROTECTED] out of the office on Monday See also our intranet site: http://www.ewt.intranet - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. -
RE: M Galbreath
I probably should not respond, but obviously I could not stop myself from doing so.. 1: How sure can we be that Mark wrote the message about him being fired over this 2: If he did write this, AND the message is true, it seems far fetched that one gets fired over just posting in this thread (although his style is far from respectable) 3: His actions in this forum (as far as I experienced it last week) is likely to trigger others to do something about it.. So he kinda brought it upon himself by provoking a maillist that should be far from name calling and showing lots of disrepect to many of us.. It should be a technical forum on the use of struts. Mark clearly violated several ethics with almost, if not all, of his posts... 4: Maybe he was not allowed to use Intenet during business hours. 5: Yes if this is the sole reason for him being fired, it is a bit over the top and the one who sent the thread summary to his director probably should not have done that. On the other hand, Mark is part of a public function and therefor has to answer to the public and therefor should have highg value of ethics.. His clear way of violating such ethics mgith be reason enough to have distrust in his addition to his public function, which kinda would make it a public's problem.. 6: bad carma? To make a long story short: he would not have anything to worry form this thread if he simply would have been polite and respectfull... Just my two cents... -Original Message- From: Larry Meadors [mailto:[EMAIL PROTECTED] Sent: woensdag 6 juli 2005 18:07 To: Struts Users Mailing List Subject: Re: M Galbreath I would like the person who sent this to know that they are the lowest form of life on the planet. Larry On 7/6/05, netsql <[EMAIL PROTECTED]> wrote: > We all all sincererly very sorry, we just wanted a slap on the wrist > from all the noise. > > .V > > > Mark Galbreath wrote: > > Thanks to whomever emailed last weeks nonsense thread to the > > Director of the Board of Elections. It made me look like a racist > > and I was fired this morning. The State is also looking into > > whether my use of an official email address for that discussion is > > in violation of state law. You did your work well, you low-life > > bastard. > > > > Signing off > > Mark > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Stinking IDEs
btw I use Eclipse 3.0.1 with several cool plugins for building and testinf my webapplications... Sofar it rocks. The new features in 3.2 make it even more user friendly and easier to work with.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: donderdag 30 juni 2005 14:28 To: user@struts.apache.org Subject: RE: [OT] Stinking IDEs I very much like the ease of use of struts (yes it need some improvements still) and everytime I encounter a lack of functionality building my JSP I will have to ask myself if this is lack of functionality or simply an attempt of me to put too much logic into the JSP... Sofar I could handle all issues with the bean,logic ad html taglibs. All other problems are solved in small almost atomic actions that do the real task and prepare the bojects for viewing.. regards Jacob -Original Message- From: Mark Galbreath [mailto:[EMAIL PROTECTED] Sent: donderdag 30 juni 2005 13:55 To: Struts Users Mailing List Subject: RE: [OT] Stinking IDEs Amen, brother! Like I said when I began this thread...Struts is dead and Java is a C# wannabie. ~mark -Original Message- From: Gregory Seidman [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 29, 2005 7:17 PM To: user@struts.apache.org Subject: Re: [OT] Stinking IDEs So I hate to feed the trolls, but... On Wed, Jun 29, 2005 at 02:35:50PM -0700, Yan Hu wrote: } Look at the job market for the server side now. 3 years ago, .Net took } only 20% of the server side market. Now it is creeping up to 40%. .Net is } better or faster than Java? Nah.. Some .Net zealots otained some } benchmarks on Tiger and .Net1.1 using linPack. Tiger outperformed .Net. } But why is .NET creeping up so fast? VS.net contributes to a great } portion of its success. One of my friends is a NET develepor. I envy his } speed of rolling out (small to medium sized) web applications like they } were egg rolls. Only the market tells what is good nor not. You have } one thousand sound reasons to back up what you claim. If the market says } "no", then it is garbage I have never liked IDEs. I have never used an IDE that didn't get in my way more than it helped. VS.NET is no exception. Below I'll give you some reasons why .NET is popular that have nothing to do with the quality, or lack thereof, of VS.NET as an IDE. I recently developed an ASP.NET web app. This involved writing in the following languages: ASP.NET (JSP-ish), C#, CSS, and JavaScript. It was only because I could convince VS.NET to let me edit these files with Vim that I did not tear out all my hair. That said, ASP.NET beats the pants off JSP. I can tell you definitively that ASP.NET's custom web control stuff (both ascx files and just plain class instances) beats hell out of JSP's tag libraries. The EL is not a big enough plus to make up for the difficulty of wrapping functionality in a custom tag. I haven't done anything significant with Struts, but I didn't have any trouble separating model, view, and controller in ASP.NET. In addition, C# is what Java always should have been. Here are a few Java mistakes that are done right in C#: 1. The language and virtual machine are internationally standardized. 2. JavaBeans use a naming convention (get/set methods), rather than first-class, syntactically clear, reflectable properties. (Yes, you find the methods by reflection, but they are "properties" because of the naming convention, not because the reflection API knows anything about properties.) 3. Namespaces (packages) are hierarchical in name, but not in scope. 4. The source filename must match the (public) class defined in it. 5. The source file must be located in a directory hierarchy that matches the package hierarchy to which it belongs. 6. C/C++ precompiler directives were simply dropped, rather than fixed to be less prone to misuse. 7. Receiving an event requires implementing an interface, with its associated method(s), and calling a method on the event producer to register the handler; producing an event requires writing add and remove handler methods, as well as writing a loop to invoke the appropriate method on each registered handler. What makes this wrong can be seen by comparing it to the C# event handling mechanism: a delegate type (essentially an OO function pointer, which includes the object reference almost exactly like Obj-C's selectors) is declared to handle a particular event, an event is declared in the producer class of the delegate type, a method with the appropriate signature can be registered with the event using += and unregistered using -=, and the handlers are invoked by the producer class by calling the event like a method. Oh, yeah, and a class's events are available through the reflection API. 8. Special casing value types (e.g. int, char, etc.), rather than either making everything a proper object (like SmallTalk) or making it possible for developer
RE: [OT] Stinking IDEs
I very much like the ease of use of struts (yes it need some improvements still) and everytime I encounter a lack of functionality building my JSP I will have to ask myself if this is lack of functionality or simply an attempt of me to put too much logic into the JSP... Sofar I could handle all issues with the bean,logic ad html taglibs. All other problems are solved in small almost atomic actions that do the real task and prepare the bojects for viewing.. regards Jacob -Original Message- From: Mark Galbreath [mailto:[EMAIL PROTECTED] Sent: donderdag 30 juni 2005 13:55 To: Struts Users Mailing List Subject: RE: [OT] Stinking IDEs Amen, brother! Like I said when I began this thread...Struts is dead and Java is a C# wannabie. ~mark -Original Message- From: Gregory Seidman [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 29, 2005 7:17 PM To: user@struts.apache.org Subject: Re: [OT] Stinking IDEs So I hate to feed the trolls, but... On Wed, Jun 29, 2005 at 02:35:50PM -0700, Yan Hu wrote: } Look at the job market for the server side now. 3 years ago, .Net took } only 20% of the server side market. Now it is creeping up to 40%. .Net is } better or faster than Java? Nah.. Some .Net zealots otained some } benchmarks on Tiger and .Net1.1 using linPack. Tiger outperformed .Net. } But why is .NET creeping up so fast? VS.net contributes to a great } portion of its success. One of my friends is a NET develepor. I envy his } speed of rolling out (small to medium sized) web applications like they } were egg rolls. Only the market tells what is good nor not. You have } one thousand sound reasons to back up what you claim. If the market says } "no", then it is garbage I have never liked IDEs. I have never used an IDE that didn't get in my way more than it helped. VS.NET is no exception. Below I'll give you some reasons why .NET is popular that have nothing to do with the quality, or lack thereof, of VS.NET as an IDE. I recently developed an ASP.NET web app. This involved writing in the following languages: ASP.NET (JSP-ish), C#, CSS, and JavaScript. It was only because I could convince VS.NET to let me edit these files with Vim that I did not tear out all my hair. That said, ASP.NET beats the pants off JSP. I can tell you definitively that ASP.NET's custom web control stuff (both ascx files and just plain class instances) beats hell out of JSP's tag libraries. The EL is not a big enough plus to make up for the difficulty of wrapping functionality in a custom tag. I haven't done anything significant with Struts, but I didn't have any trouble separating model, view, and controller in ASP.NET. In addition, C# is what Java always should have been. Here are a few Java mistakes that are done right in C#: 1. The language and virtual machine are internationally standardized. 2. JavaBeans use a naming convention (get/set methods), rather than first-class, syntactically clear, reflectable properties. (Yes, you find the methods by reflection, but they are "properties" because of the naming convention, not because the reflection API knows anything about properties.) 3. Namespaces (packages) are hierarchical in name, but not in scope. 4. The source filename must match the (public) class defined in it. 5. The source file must be located in a directory hierarchy that matches the package hierarchy to which it belongs. 6. C/C++ precompiler directives were simply dropped, rather than fixed to be less prone to misuse. 7. Receiving an event requires implementing an interface, with its associated method(s), and calling a method on the event producer to register the handler; producing an event requires writing add and remove handler methods, as well as writing a loop to invoke the appropriate method on each registered handler. What makes this wrong can be seen by comparing it to the C# event handling mechanism: a delegate type (essentially an OO function pointer, which includes the object reference almost exactly like Obj-C's selectors) is declared to handle a particular event, an event is declared in the producer class of the delegate type, a method with the appropriate signature can be registered with the event using += and unregistered using -=, and the handlers are invoked by the producer class by calling the event like a method. Oh, yeah, and a class's events are available through the reflection API. 8. Special casing value types (e.g. int, char, etc.), rather than either making everything a proper object (like SmallTalk) or making it possible for developers to define value types. I'll admit that Java has gotten better with the release of 1.5, and about damn time. It has generics, which are not yet available in C# (currently in beta). It also has anonymous classes, which are primarily valuable for event handling. Java now has the enhanced for loop (C#'s foreach), automatic un-/boxing (C# has it), and typesafe enums (C#
RE: problem while displaying error message
First: It seems wrong to tell the user that an id does not exist! It
goesd against security conventions!
Second.. I think you should do something like this:
errors.add(Application.GLOBAL_ERRORS, new
ActionError("err.app.login.invalid",txtLoginId ));
With your ,messageresource having a line:
err.app.login.invalid={0}, login id does not exits.
regards
-Original Message-
From: Khan [mailto:[EMAIL PROTECTED]
Sent: vrijdag 24 juni 2005 11:33
To: user@struts.apache.org
Subject: problem while displaying error message
Hi,
Iam using Struts1.0 ActionErrors and ActionError object to
store/display
errors which is reading the errors from ApplicationResources file. Iam
unable to display the error for dynamically generated values. Any idea
please.
My Code:
String txtLoginId = "Manager" ; // txtLoginId value comes dynamically
as
entered by the user
ActionErrors errors = new ActionErrors();
errors.add(Application.GLOBAL_ERRORS, new ActionError("
err.app.login.invalid")); // This works fine. The proper error which is
given in resources file will be shown in the html page.
String errMsg = txtLoginId +" , login id does not exits.";
errors.add(Application.GLOBAL_ERRORS, new ActionError(errMsg)); // This
also works fine, but how to show this errMsg value in the html file by
Thanks in advance.
Regards
Khan
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.
Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to find the cause of the error
Jeroen,
I would put a try catch block around the getBlogItem method:
public Iterator getBlogItem()
{
try {
Session session =
HibernateUtil.currentSession();
Transaction tx = session.beginTransaction();
Query query = session.createQuery("select b
from BlogItem as b");
blogItem = query.iterate();
tx.commit();
HibernateUtil.closeSession();
return blogItem;
}
} catch (Throwable t){
System.out.println("Error in getBlogItem: "+t);
t.printStackTrace();
throw new Error("check your logs for errors"); // so it
exits the method as it should
}
}
Regards,
Jacob
-Original Message-
From: Jeroen P [mailto:[EMAIL PROTECTED]
Sent: vrijdag 24 juni 2005 11:28
To: Struts-User
Subject: How to find the cause of the error
Hi,
I've got a prolbem with finding the error in my code.
I'm trying to integrate Hibernate in my application.
Tomcat gives a stack trace, but it didn't give a line
number where the error occurred. It looks like it goes
wrong with the logic:iterator in my JSP page and the
BlogItem getter in BlogBean. I'm using Netbeans 4.1 as
my IDE.
Does anybody know how I can find where it goes wrong ?
This is my JSP page:
<%@ taglib uri="/tags/struts-bean" prefix="bean" %>
<%@ taglib uri="/tags/struts-html" prefix="html" %>
<%@ taglib uri="/tags/struts-logic" prefix="logic" %>
Blog
Blog
This is the error message:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error
() that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: Exception thrown by
getter for property blogItem of bean blog
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageCont
extImpl.java:846)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContex
tImpl.java:779)
org.apache.jsp.pages.Blog_jsp._jspService(Blog_jsp.java:153)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:99)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:325)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:245)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFi
lter.java:362)
org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.jav
a:1063)
org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProc
essor.java:263)
org.apache.struts.action.RequestProcessor.internalModuleRelativeForward(
RequestProcessor.java:1001)
org.apache.struts.tiles.TilesRequestProcessor.internalModuleRelativeForw
ard(TilesRequestProcessor.java:345)
org.apache.struts.action.RequestProcessor.processForward(RequestProcesso
r.java:560)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
209)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFi
lter.java:362)
root cause
javax.servlet.jsp.JspException: Exception thrown by
getter for property blogItem of bean blog
org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:968)
org.apache.struts.taglib.logic.IterateTag.doStartTag(IterateTag.java:232
)
org.apache.jsp.pages.Blog_jsp._jspService(Blog_jsp.java:108)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:99)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:325)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:245)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFi
lter.java:362)
org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.jav
a:1063)
org.apache.struts.tiles.TilesRequestProcessor.doForward(TilesRequestProc
essor.java:263)
org.apache.struts.action.RequestProcessor.internalModuleRelativeForward(
RequestProcessor.java:1001)
org.apache.struts.tiles.TilesRequestProcessor.internalModuleRelativeForw
ard(TilesRequestProcessor.java:345)
org.apache.struts.action.RequestProcessor.processForward(RequestProcesso
r.java:560)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
209)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.
RE: ApplicationResources.properties vs Validator framework
First thing that comes to mind is that you likely forgot to add the key to the resource.. Try adding the null="true" option to your resource declarations in struts-config.xml -Original Message- From: Gilbert, Antoine [mailto:[EMAIL PROTECTED] Sent: donderdag 23 juni 2005 15:41 To: Struts Users Mailing List Subject: RE: ApplicationResources.properties vs Validator framework No Struts is trying to load application_fr_CA.properties, and anyway I have no application.properties, I have an ApplicationResources.properties. One more problem to go before the problem you talking about. -Original Message- From: Nitish Kumar [mailto:[EMAIL PROTECTED] Sent: June 23, 2005 9:38 AM To: 'Struts Users Mailing List' Subject: RE: ApplicationResources.properties vs Validator framework To me it seems, due to a different locale, your application is looking for ApplicationResources_fr_CA.properties you can try renaming your properties file to "ApplicationResources_fr_CA.properties" and then deploying the application. Thanks and Regards, Nitish Kumar Tavant Technologies Ltd Bangalore -Original Message- From: Gilbert, Antoine [mailto:[EMAIL PROTECTED] Sent: Thursday, June 23, 2005 6:09 PM To: Struts Users Mailing List Subject: ApplicationResources.properties vs Validator framework Hi I have a strange problem. I have an application using validator on server side and client side (javascript), I have an ApplicationResources.properties with all my messages for erreor messages from validations. All is working ok. But, I made a war file and deployed the application on another server, and all validations error messages are now empty. ApplicationResources.properties is there, and I have this line in my struts-config.xml : I activated logs via log4j, and I'm not getting any significant information except maybe this (I don't see him load ApplicationResources.properties) : DEBUG [org.apache.struts.action.RequestProcessor][23-06-2005 08:29:42]: processForwardConfig(ForwardConfig[name=default,path=/console/Contenu.js p?contenu=/console/sections/EditMenuLocale.jsp,redirect=false,contextRel ative=false,module=null]) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: getMessage(fr_CA,errors.required) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale(fr_CA) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: Loading resource 'resources/application_fr_CA.properties' DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: Loading resource completed DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale(fr) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: Loading resource 'resources/application_fr.properties' DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: Loading resource completed DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale() DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: Loading resource 'resources/application.properties' DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: Loading resource completed DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: getMessage(fr_CA,errors.maxlength) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale(fr_CA) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale(fr) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale() DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: getMessage(fr_CA,errors.maxlength) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale(fr_CA) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale(fr) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale() DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: getMessage(fr_CA,errors.maxlength) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale(fr_CA) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale(fr) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale() DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: getMessage(fr_CA,errors.maxlength) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale(fr_CA) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale(fr) DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:29:43]: loadLocale() DEBUG [org.apache.struts.util.PropertyMessageResources][23-06-2005 08:30
