RE: HELP - "Illegal target of jump or branch"

2001-03-20 Thread McCay, Larry

Marc,

This may be related to the size of you resulting jspservice method.

If that is the case you need to break it up into multiple includes - as
recommended to someone else earlier today.

lar

-Original Message-
From: Marc Ellison [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 3:07 PM
To: '[EMAIL PROTECTED]'
Cc: Kyle Robinson
Subject: HELP - "Illegal target of jump or branch" 


Hi,

I have been getting a very interesting error folks ;-)

I have constructed a jsp file that uses ALOT of struts-defined tags, and
which I have running with Tomcat.  Initially the page would not work so I
commented out a lot of the code.  The page now works to an extent, but as
soon as I try to uncomment any of the other struts tags it throws this error
message.

javax.servlet.ServletException: (class:
_0002fdemographicDetails_0002ejspdemographicDetails_jsp_73, method:
_jspService signature:
(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletRespo
nse;)V)

I have looked in the mail archive and one guy suggested changing the values
of the stack/memory allocation pools to a higher value as it couldn't cope
with the number of tags.  However, I still get the same error. Has anybody
encountered a similar problemif so please HELP!!
Kind regards
Marc



RE: Sample Servlet Controller

2001-02-27 Thread McCay, Larry

nagesh,

I am not sure what you are asking for.

You are able to write a vendor neutral app using the bluestone servlet
engine.

If you elaborate a bit I can offer some advice.

You can get to a Trail Map on the gallery website for further information

http://gallery.bluestone.com/scripts/SaISAPI.dll/Gallery.class/demos/trailMa
ps/index.jsp

thanks,

Larry

-Original Message-
From: Nageshwar Charka [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 27, 2001 10:47 AM
To: '[EMAIL PROTECTED]'
Subject: Sample Servlet Controller


Hi there,

Can somebody help me in getting some sample code snippet for Struts Servlet
Controller(Struts Application startup Servlet).
Currently I am using SaServletEngine.class as the controller from Bluestone
Software(HP).
It just works fine, but I want to make a vender neutral app.

Thanks in advance

-nagesh



RE: Template tags?

2001-02-20 Thread McCay, Larry

The 1.0 release will be officially released very shortly.

In the mean time I suggest you use the latest nightly builds as they are
very nearly what the final 1.0 release will be. 

As far as the template tags I am not familiar enough with them to comment.

But, with jsp:include you can easily add your navigation bar.

-Original Message-
From: John Nikolai
To: [EMAIL PROTECTED]
Sent: 2/20/01 7:31 PM
Subject: Template tags?


Hi all!

I'm defiantly new to the struts and taglibs so please bear with my
questions:

We are writing a proof of concept to see if struts will meet our needs
for 
a non-profit customer we are working with. Several questions have come
up 
during this process. First off,  the web pages we will be creating will 
have a common navigation bar used across the whole web site. It would be

great if we can create one HTML file called navigation.jsp which all
pages 
use. It seems that the struts template taglibs might be the solution, 
unfortunately the 0.5 version of struts we downloaded does not contain 
these taglibs. The template taglibs are in CVS and easily accessed but
I'm 
wondering if these are going to be distributed in the next release of 
struts. Also I'm wondering if the template taglibs will suit our needs.
Any 
other solutions to the above problem would be greatly appreciated.

OK, this was only one question. I'm sure as we move along with the proof
of 
concept more will pop up.

Thanks for all your help,
  - John



RE: struts portability.

2001-02-20 Thread McCay, Larry



Backward compatibility is an ongoing priority from 1.0 
out.
 
The 
idea, as I have understood it, has been to make as many non-backward 
compatible changes as possible before the 1.0 release to help alleviate the need 
for them later.

  -Original Message-From: Peri Srinivas 
  [mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 20, 2001 1:41 
  PMTo: [EMAIL PROTECTED]Subject: struts 
  portability.
  Hi ,
      I just bumped  on to 
  project  where  I  had  a  code base  working 
  with 0.5 version of Struts.
      After replacing with 1.0  
  i discovered  there  were  quite a   bunch of chages 
  like.
          
  1)ValidatingActionForm  --changed from Interface  to 
  class.
          2)Methods 
  of ActionBase changed thier  signatures.
          
          eg: 1)getResources
          
              
    2)saveErrors.
   
     Can  we assume 
  the backWord  compatiblity  
  of  1.0  when   we have 
  future versions.
   
   
  T,
  Peri


RE: GenericDataSource Enhancement

2001-01-04 Thread McCay, Larry

My vote would be to hold off until 1.0 is released to add enahancements.

Let's concentrate on the outstanding documentation and any critical bugs.

thanks,

larry

-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 04, 2001 6:46 PM
To: [EMAIL PROTECTED]
Subject: Re: GenericDataSource Enhancement


David Winterfeldt wrote:

> I don't see GenericDataSource checking to see if a
> connection is dead/closed before it returns it from
> the pool.  I think my ISP shuts down the database at
> night for backups and it kills the connection pool.
>
> Could checking to see if the connection is live
> (reconect if dead) be added?
>

It certainly could, along with other stuff like implementing the
getConnection(username, password) call correctly.

Does it need to be fixed within the next few days (i.e. before a 1.0
release),
or are these enhancements we can worry about after 1.0 is released?

>
> David Winterfeldt
>

Craig




RE: Proposal: RetroFit Struts with the Delegation Event Model

2000-12-27 Thread McCay, Larry

I agree - I would like to see the inclusion of events for any and all
interesting events.

I think the following article link may be of some interest as well:

http://www.sys-con.com/java/archives/0601/grant/

It includes an interesting implementation of events for template based
processing - for pre and post processing of jsp includes.  I like the
concepts of a Document class and ModelContext.

Personally, I would like to see a View class/interface and ViewContext and
Controller class/interface and Controller Context as well.

Coupled with appropriate event subscriptions and notifications Struts would
more closely resemble the original MVC model.

It would be interesting to use this notification mechanism to allow for
multiple Views to be notified of Model Change Events.  This would open the
door ( a little wider at least ) for other types of application development
such as B2B.

The controller seems the appropriate place from which to fire events.

* Single ActionEvent class, or subclasses for various types
  of events that have different properties (some events care
  about the current ActionMapping and some don't).

Subclasses

* SIngle registrations of ActionListeners that receive all types of
  events, or separate registrations for separate event families?

Seperate event listener registrations for event families seems the cleanest
implementation and would eliminate event-storm like activity.

* An ActionEvent, or the ActionListener that receives it,
  should have knowledge of the ActionServlet
  it is associated with, to provide access to underlying resources
  provided by the servlet.  (The whole event listener model is
  intimately tied to Struts anyway, so this does not seem onerous).

This would be a good place for the Controller class/interface and
ControllerContext.

Just my 2 cents.

Thanks,

Larry

-Original Message-
From: Craig R. McClanahan
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: 12/26/00 9:57 PM
Subject: Re: Proposal: RetroFit Struts with the Delegation Event Model

I like the basic idea of event listeners for Struts events.  About the
particular proposal, though, I've got some comments and questions I
would like
feedback on.

* As fleshed out, the only events reported with this model so far
  are before and after an Action's perform() method is called.
  The abstract talks about building listeners for all "interesting"
  events.  If we're going to do a listeners model, I think we should
  extend it to basically all of the processXxx methods, not just
  processPerform().

* If we go with generalized events, putting the firing logic inside
  Action seems wrong -- general purpose support classes, or
  public methods inside ActionServlet, seem more appropriate.

* Given that there will be many more events, we've got some
  representation choices:

* Single ActionEvent class, or subclasses for various types
  of events that have different properties (some events care
  about the current ActionMapping and some don't).

* SIngle registrations of ActionListeners that receive all types of
  events, or separate registrations for separate event families?

* I also have a couple of nit-picky type thoughts:

* Event type codes inside the ActionEvent seem redundant,
  given that the type is implicitly defined by which listener
  method you call.

* An ActionEvent, or the ActionListener that receives it,
  should have knowledge of the ActionServlet
  it is associated with, to provide access to underlying resources
  provided by the servlet.  (The whole event listener model is
  intimately tied to Struts anyway, so this does not seem onerous).

* We need to use collection classes (with an implementation I'm
  currently working on) that do not require lots of synchronization
locks
  or new object creations when processing event notifications, since
  they happen on every request.

Thoughts?

Craig



David Geary wrote:

> ABSTRACT
>
> It's often convenient, and sometimes necessary, to handle Struts
events,
> such as when an action has its locale set, or when the action servlet
> processes an action's form. This document proposes retrofitting Struts
> with the delegation event model. That model, which is used by the AWT
> and
> Swing, makes event handling simple, flexible, and scalable.
>
> CREDITS
>
> Delegation and Event Model for Struts? -- posted to struts-dev by
>   Robert Leland
>
> INTRODUCTION
>
> Currently, you can use inheritance to handle Struts events like those
> described above. Typically, that means extending ActionServlet and
> overriding a protected method, such as
> ActionServlet.processActionPerform.
>
> Inheritance-based event handling is inflexible and does not scale well
> because event sources and listeners are tightly coupled at compile
time.
> This was evident to AWT engineers, who replaced the AWT's original
> inher

RE: Urgent help !!

2000-12-21 Thread McCay, Larry
Title: Urgent help !!




    Check that your web.xml file has load-on-startup set for 
ActionServlet as below:
 
 
- <servlet>


  <servlet-name>actionservlet-name> 

  <servlet-class>org.apache.struts.action.ActionServletservlet-class> 


- <init-param>


  <param-name>applicationparam-name> 

  <param-value>trialtest.HelloWorldResourcesparam-value> 
  </init-param>

  <load-on-startup>1load-on-startup> 
 servlet>
 
[McCay, Larry] 
 
 
 -Original Message-From: Laufer, 
Michael [mailto:[EMAIL PROTECTED]]Sent: Thursday, December 
21, 2000 11:30 AMTo: 'Struts'Subject: Urgent help 
!!

  Hi there, today 
  I've set up a new webapplication with Struts. Now I'm facing the following exception when I'm trying to start the 
  application. 
  Error: 500 Location: /diplomMILA/index.jsp 
  Internal Servlet Error: 
  javax.servlet.ServletException: Missing 
  resources attribute org.apache.struts.action.MESSAGE 
      at 
  org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:386) 
      at 
  _0002findex_0002ejspindex_jsp_2._jspService(_0002findex_0002ejspindex_jsp_2.java, 
  Compiled Code)     at 
  org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:126) 
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 
      at 
  org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.java:174) 
      at 
  org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:261) 
      at org.apache.jasper.runtime.JspServlet.service(JspServlet.java, 
  Compiled Code)     at 
  javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 
      at 
  org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java, 
  Compiled Code)     at 
  org.apache.tomcat.core.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:163) 
      at 
  org.apache.tomcat.servlets.DefaultServlet.doGet(DefaultServlet.java:187) 
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) 
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 
      at 
  org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java, 
  Compiled Code)     at 
  org.apache.tomcat.core.ContextManager.service(ContextManager.java:559) 
      at 
  org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:160) 
      at 
  org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java, 
  Compiled Code)     at java.lang.Thread.run(Thread.java:479) 
  Root cause: javax.servlet.jsp.JspException: Missing resources attribute 
  org.apache.struts.action.MESSAGE 
      at 
  org.apache.struts.taglib.MessageTag.doStartTag(MessageTag.java:360) 
      at 
  _0002findex_0002ejspindex_jsp_2._jspService(_0002findex_0002ejspindex_jsp_2.java, 
  Compiled Code)     at 
  org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:126) 
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 
      at 
  org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.java:174) 
      at 
  org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:261) 
      at org.apache.jasper.runtime.JspServlet.service(JspServlet.java, 
  Compiled Code)     at 
  javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 
      at 
  org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java, 
  Compiled Code)     at 
  org.apache.tomcat.core.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:163) 
      at 
  org.apache.tomcat.servlets.DefaultServlet.doGet(DefaultServlet.java:187) 
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) 
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) 
      at 
  org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java, 
  Compiled Code)     at 
  org.apache.tomcat.core.ContextManager.service(ContextManager.java:559) 
      at 
  org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:160) 
      at 
  org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java, 
  Compiled Code)     at java.lang.Thread.run(Thread.java:479) 
  
  I'm totally confused. something must be terribly 
  wrong with classpath or so. but don't ask me, I'm trying to fix it now 
  for
  two hours without any success. Maybe somebody out there finds the error immediately. 
  By the way I'm using Tomcat 3.1. The strange thing is, that I've set a couple of applications 
  with Struts before. Maybe it's really time 
  for holiday :-)) Any help would be 
  appreciated. 
  Thanks in advance, 
  Miek 


RE: What about this model?

2000-12-16 Thread McCay, Larry

This concept is something that I have been contemplating for sometime.  I
have been recently working on a framework for Horizontal Application
Services - these application services are to Federated and Collaborative.
This framework would allow for interface based programming from the jsp
pages and within the tag handlers.  By providing a centrally available
ServiceManager that is responsible for the lifecycle of each of its managed
services, the jsp and tag handler developer can request the registered
service for a particular interface.  Services collaborate by having access
to the properties of one another as well as being able to register as
property change listeners of one another.  Each service needs to be
configured to be run within an appropriate scope for the application.  Some
services can run within application scope, some need to be at session and
still others would probably be best at request ( such as your stateManager
idea ).

One of the services I plan to implement is a PresentationService for exactly
the reasons you state - plus the ability to provide presentation related
resources such as Type Table information to fill drop down boxes, Localized
Content through logical content resolution and etc.  This functionality can
be provided by collaborating with other services such as the I18N Service
for internationalization and localization and ContentDeliveryService for
logical content.  This service would need to be run within the request scope
so that you don't end up with state from previous requests cluttering up the
service or the need to garbage collect it manually.

A word of caution - you need to to take care in providing any state machine
functionality within a servlet ( controlling servlet or not ) due to the
fact that there is only one servlet instance running per web app.  So, you
will have multiple requests being processed by the same servlet instance -
you therefore have serious concurrency issues.  It is good practice to not
have any instance variables in a servlet - especially any that need to be
updated at the session or request levels.

Any thoughts on the application services framework?

thanks,

larry

-Original Message-
From: Dan Cancro [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 15, 2000 5:42 PM
To: [EMAIL PROTECTED]
Subject: RE: What about this model?


That would work too.  I made it a separate object because the concepts of
flow control and data holding seemed separable enough to me that they should
go in different classes.  I can imagine a scenario where you want one kind
of flow controller, but you would want state managed in one of a few
different ways depending on the client's capacity for holding it.  If I
implemented this, I would make the StateManager an instance property of the
ActionServlet.

-Original Message-
From: Ian.Swett [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 15, 2000 2:34 PM
To: [EMAIL PROTECTED]
Subject: Re: What about this model?


I don't have much experience with struts either, but what about having the
controlling servlet do the state management, rather than adding another
component to do so.  The concept of a StateManager of some sort for data
storage, etc seems important.
Besides that, I really like it, but I'd like to hear what others think.
Ian Swett



RE: newbie question regarding performance

2000-10-26 Thread McCay, Larry

Scott,

Scalability can be handled by the load-balancing techniques that you apply
to your site.  These mechanisms may be web farm configurations or
application server deployment options.

For example Bluestone Software's Total-e-Server (UBS) is typically deployed
across multiple application hosts running multiple vm's.  The Load Balance
Broker (LBB) determines the optimal vm on the most appropriate application
host to dispatch the request to.

These types of approaches resolve high volume scalability before it actually
reaches the web application itself.

Having a single controlling servlet provides a single entry point to the
application which becomes a convienient place to do many things that would
otherwise be distributed accross your whole application - for instance form
validation and repopulation of for elements in the event of input errors,
authenticated a user, personalizing the application look and feel or
collection of clickstream information.

I hope this was helpful.

Larry

-Original Message-
From: Sayles, Scott SAXONHQ [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 26, 2000 5:29 PM
To: '[EMAIL PROTECTED]'
Subject: newbie question regarding performance



I'm relatively new to Struts and MVC based architecture for Web
applications.  What are the implications to using a single controlling
servlet for a high volume site?  i.e. do I have to worry about performace in
regards to using a single ActionServlet for all our requests?


Thanks

Scott



interfaces vs base classes

2000-10-24 Thread McCay, Larry

Greetings,

I may have missed a previous discussion on this topic - if so I apologize.

I am wondering if someone could explain why we have changed to base classes
from interfaces for the Action and FormAction files.

Typically, I provide an interface an abstract implementation and sometimes a
default implementation of that.  I have thought that this provided the
greatest level of flexibility.

A couple things strike me as odd:

1. We are now limited to extending a single base class instead of
implementing the appropriate interface in a class which extends the most
meaningful base

2. We have also broken any existing customer code that implements them
directly - we won't want to make changes like this after 1.0 release

Thanks in advance,

Larry