Extending ActionServlet
Can anyone point me to a code example which extends ActionServlet?
I tried the most simplest way I could think of but it didn't work:
package my.pack;
import java.io.IOException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;
import org.apache.struts.util.RequestUtils;
public final class Controller extends
org.apache.struts.action.ActionServlet
{
protected void process(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException {
System.out.println(Controller in place);
super.process(request,response);
}
}
web.xml change of:
servlet-classmy.pack.Controller/servlet-class
what else would I have to do?
Re: RE: Accessing EJB references by extending ActionServlet
Thanks for the reply. I was planning to put the look up of the EJB
reference in the init method of the servlet, so unless Iam missing
something, It should be thread safe. I looked at the java pet store
source code specifically at WebControllerImpl. I found that , it looks
up the EJB reference in a non synchronized method. All the other
methods that access the EJB are synchronized, Does that mean lookups in
general are thread safe?
Appreciate your help,
Sunder
- Original Message -
From: James Dasher [EMAIL PROTECTED]
Date: Tuesday, January 8, 2002 7:20 pm
Subject: RE: Accessing EJB references by extending ActionServlet
Uh, careful--synchronization issues (immediate problem) and data
abstraction (long term problem).
Servlets are not thread-safe, so be very careful handing that
referencearound.
Also, do you want your struts stuff knowing about EJB? EJB is
complicated.
Possible alternatives:
1. Use session-scope beans as web-tier Helpers, abstracting data-
accessimplementation. (Your actions don't really need to know how
to use an
EJB, do they?)
2. Consider adding a service locator, which implements
HttpSessionListener, which binds itself in session and knows how to
get/create above Helper objects
3. Value object are a pretty good idea, too.
4. (Extreme) Have a single point of entry into the EJB tier, a
controller which has one operant method, something like
public synchronized ModificationResponse
handleModification(Modification Request) {}
public interface ModificationRequest {
public String getName();
}
public interface ModifcationResponse {
public Object getPayload();
}
Your controller (a stateful EJB) can delegate to various other
EJB's based on an XML file or environment entries with
ModificationRequest.getName() as the key.
Your Data-Access Objects can take that response, grab the
payload, and put it in session as needs be.
Then your actions can just grab what they need likewise:
Locator l =
(Locator)request.getSession().getAttribute(Keys.SERVICE_LOCATOR)
Carthelper c = l.getCartWebhelper();
request.setSessionAttribute(Keys.SHOPPING_CART,c.addStuffToCart
(someItem
))
where addStuffToCart returns some kind of Value Object
you can expose as a bean. Meanwhile, your cart has been updated
back in
the EJB's somewhere.
Most of this is ripped straight from the pages of the petstore
demo Web
Application Framework. If you haven't read it, it is worth it. The
part you are looking for is
petstore1.3/src/waf/src/controller/com/sun/j2ee/blueprints/waf
Remember--Sun pushes EJB so you buy bigger appservers. Basically, 90%
of the projects using EJB don't have to. If you are in the other 10%,
then your project is large-scale enough to merit some extra time
thinking about data abstraction.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 08, 2002 9:17 PM
To: Struts Users Mailing List
Subject: Accessing EJB references by extending ActionServlet
Hello,
I have a design question about accessing EJB references from the
servlet. I would like to obtain a reference to my proxy session
bean in
the init of the servlet and use that reference to call methods on
the
bean from the action classes. I have extended the ActionServlet
and
added additional code to the init method for the EJB lookup. I
would
like to know how I can pass the remote reference across the
different
action classes? I am not sure if putting the remote reference in
session would be a good idea. I have all my action classes extend
from
the new ExtendedActionServlet
Sunder
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Accessing EJB references by extending ActionServlet
Hello, I have a design question about accessing EJB references from the servlet. I would like to obtain a reference to my proxy session bean in the init of the servlet and use that reference to call methods on the bean from the action classes. I have extended the ActionServlet and added additional code to the init method for the EJB lookup. I would like to know how I can pass the remote reference across the different action classes? I am not sure if putting the remote reference in session would be a good idea. I have all my action classes extend from the new ExtendedActionServlet Sunder -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Accessing EJB references by extending ActionServlet
Uh, careful--synchronization issues (immediate problem) and data
abstraction (long term problem).
Servlets are not thread-safe, so be very careful handing that reference
around.
Also, do you want your struts stuff knowing about EJB? EJB is
complicated.
Possible alternatives:
1. Use session-scope beans as web-tier Helpers, abstracting data-access
implementation. (Your actions don't really need to know how to use an
EJB, do they?)
2. Consider adding a service locator, which implements
HttpSessionListener, which binds itself in session and knows how to
get/create above Helper objects
3. Value object are a pretty good idea, too.
4. (Extreme) Have a single point of entry into the EJB tier, a
controller which has one operant method, something like
public synchronized ModificationResponse
handleModification(Modification Request) {}
public interface ModificationRequest {
public String getName();
}
public interface ModifcationResponse {
public Object getPayload();
}
Your controller (a stateful EJB) can delegate to various other
EJB's based on an XML file or environment entries with
ModificationRequest.getName() as the key.
Your Data-Access Objects can take that response, grab the
payload, and put it in session as needs be.
Then your actions can just grab what they need likewise:
Locator l =
(Locator)request.getSession().getAttribute(Keys.SERVICE_LOCATOR)
Carthelper c = l.getCartWebhelper();
request.setSessionAttribute(Keys.SHOPPING_CART,c.addStuffToCart(someItem
))
where addStuffToCart returns some kind of Value Object
you can expose as a bean. Meanwhile, your cart has been updated back in
the EJB's somewhere.
Most of this is ripped straight from the pages of the petstore demo Web
Application Framework. If you haven't read it, it is worth it. The
part you are looking for is
petstore1.3/src/waf/src/controller/com/sun/j2ee/blueprints/waf
Remember--Sun pushes EJB so you buy bigger appservers. Basically, 90%
of the projects using EJB don't have to. If you are in the other 10%,
then your project is large-scale enough to merit some extra time
thinking about data abstraction.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 08, 2002 9:17 PM
To: Struts Users Mailing List
Subject: Accessing EJB references by extending ActionServlet
Hello,
I have a design question about accessing EJB references from the
servlet. I would like to obtain a reference to my proxy session bean in
the init of the servlet and use that reference to call methods on the
bean from the action classes. I have extended the ActionServlet and
added additional code to the init method for the EJB lookup. I would
like to know how I can pass the remote reference across the different
action classes? I am not sure if putting the remote reference in
session would be a good idea. I have all my action classes extend from
the new ExtendedActionServlet
Sunder
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Extending ActionServlet for User Authorisation
Has anybody got an example of how they have extended ActionServlet to provide User Authentication ? Best Regards Alan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Problem with resources when extending ActionServlet
I have had no problems doing this - what does your sub-class look like? If you are overriding the init() method, you need to call super.init() to make sure the application resources are initialized. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 27 June 2001 13:21 To: [EMAIL PROTECTED] Subject: Problem with resources when extending ActionServlet The struts documentation states than extending ActionServlet is unproblematic. However, as soon as I do this (regardless of the subclass's functionality), I run into the following exception: Internal Servlet Error: javax.servlet.ServletException: Cannot find message resources under key org.apache.struts.action.MESSAGE at javax.servlet.ServletException.(ServletException.java:161) winmail.dat
Problem with resources when extending ActionServlet
BDY.RTF
RE: Problem with resources when extending ActionServlet
Make sure you call super.init() in the init() method of your subclass. Fr. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 27 June 2001 14:21 To: [EMAIL PROTECTED] Subject: Problem with resources when extending ActionServlet The struts documentation states than extending ActionServlet is unproblematic. However, as soon as I do this (regardless of the subclass's functionality), I run into the following exception: Internal Servlet Error: javax.servlet.ServletException: Cannot find message resources under key org.apache.struts.action.MESSAGE at javax.servlet.ServletException.(ServletException.java:161) at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContex tImpl.java:459) at _0002ftest_0002ejsptest_jsp_1._jspService(_0002ftest_0002ejsptest_jsp_1. java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServle t.java:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.jav a:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(H ttpConnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java(Com piled Code)) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:49 8) at java.lang.Thread.run(Thread.java:481) Root cause: javax.servlet.jsp.JspException: Cannot find message resources under key org.apache.struts.action.MESSAGE at javax.servlet.jsp.JspException.(JspException.java:73) at org.apache.struts.util.RequestUtils.message(RequestUtils.java:568) at org.apache.struts.taglib.bean.MessageTag.doStartTag(MessageTag.java:239) at _0002ftest_0002ejsptest_jsp_1._jspService(_0002ftest_0002ejsptest_jsp_1. java:68) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServle t.java:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:391) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.jav a:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(H ttpConnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java(Com piled Code)) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:49 8) at java.lang.Thread.run(Thread.java:481) This is running under Tomcat 3.2.1. Any ideas? The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com ***
Re: Extending ActionServlet
Hi, to have multiple struts-config files were nice. But you must take care in defining actions, because multiple config files were merged to only one file. To avoid this, is there a way to have more than one ActionServlet with fully seperated struts-config files in the same web application context? Thomas On Tue, 19 Jun 2001, Dan Miser wrote: Craig, There are a few problems with that approach: 1. If you just have multiple struts-config elements, you end up not having a root element. That will cause the Digester to throw an exception when starting up. Argh, I knew there had to be some fly in the ointment ... 2. So I added an element named root and put multiple struts-config elements under the root. The problem then becomes the code in the ActionServlet is looking for struts-config to be the root element. 3. Next, I extended the ActionServlet and overrode the initDigester method, changing the calls in the digester to reference */struts-config everywhere. That would work, but AddDataSourceRule is a private class, so I had to copy that from ActionServlet. After changing web.xml to use my new ActionServlet, I was able to get a module approach with a reorganized struts-config.xml from struts-example (I broke it up into global, login, registration, subscription, and admin). Worked beautifully. Of course, the struts-config.dtd would need to reflect this rework too. That seems like an approach worth considering, since it doesn't break old struts-config.xml files, -- Dan Miser http://www.distribucon.com Craig - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] I haven't actually tried this, but conceptually it should work -- could someone please try it and confirm to the list? The basic thought is that a single struts-config.xml file can actually have more than one struts-config section in it. Given, this you can logically divide your overall configuration into modules or whatever, and have each development group maintain their own stuff in their own struts-config.xml file. Then, when you deploy the app, part of the process would be simply combining all the struts-config.xml files into a single one (simple concatenation). It's worth a shot ... Craig -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- GMX Tipp: Machen Sie Ihr Hobby zu Geld bei unserem Partner 11! http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
Re: Extending ActionServlet
Sure. Specify multliple config parameters in web.xml would be the first thing I would think of trying. I don't see why merging to one file is a big deal. Part of your build script (via Ant, perhaps) would be a step that would concat the files together. -- Dan Miser http://www.distribucon.com - Original Message - From: Thomas Siedschlag [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 3:34 AM Subject: Re: Extending ActionServlet to have multiple struts-config files were nice. But you must take care in defining actions, because multiple config files were merged to only one file. To avoid this, is there a way to have more than one ActionServlet with fully seperated struts-config files in the same web application context?
Re: Extending ActionServlet
I dont understand. Noone has to concat anything. You can include xml fragments in your master struts-config.xml like this: !DOCTYPE project [ !ENTITY header SYSTEM file:///config1.inc !ENTITY common SYSTEM file:///config2.inc ] where config1.inc is a file with xml fragments of parameters and config2.inc is a file with xml fragments of more parameters. You just point to the file. Wantto take them out? Pull them out of the top of struts-config.xml - Original Message - From: Dan Miser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 10:07 AM Subject: Re: Extending ActionServlet Sure. Specify multliple config parameters in web.xml would be the first thing I would think of trying. I don't see why merging to one file is a big deal. Part of your build script (via Ant, perhaps) would be a step that would concat the files together. -- Dan Miser http://www.distribucon.com - Original Message - From: Thomas Siedschlag [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 3:34 AM Subject: Re: Extending ActionServlet to have multiple struts-config files were nice. But you must take care in defining actions, because multiple config files were merged to only one file. To avoid this, is there a way to have more than one ActionServlet with fully seperated struts-config files in the same web application context?
Re: Extending ActionServlet
On Wed, 20 Jun 2001, Thomas Siedschlag wrote: Hi, to have multiple struts-config files were nice. But you must take care in defining actions, because multiple config files were merged to only one file. Also true for global forwards, form bean definitions, data sources, etc. To avoid this, is there a way to have more than one ActionServlet with fully seperated struts-config files in the same web application context? That is also a highly requested feature. It's going to take some interesting internal rework to pull this off, because right now the major configuration objects that Struts builds are exposed as servlet context attributes under a single name. Thomas Craig
Re: Extending ActionServlet
I tried using entity references before with no luck. After reading this post, I just tried again, and it doesn't work. Do you have a working example of how to split the struts-config.xml from struts-example into modules (e.g. global, logon, subscription, registration, and admin)? I haven't looked at it, but I'm guessing the problem is in the Digester. Assuming entity references don't work, I outlined the reasoning for the approach I took in a previous message in this thread. -- Dan Miser http://www.distribucon.com - Original Message - From: Jonathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 10:35 AM Subject: Re: Extending ActionServlet I dont understand. Noone has to concat anything. You can include xml fragments in your master struts-config.xml like this: !DOCTYPE project [ !ENTITY header SYSTEM file:///config1.inc !ENTITY common SYSTEM file:///config2.inc ] where config1.inc is a file with xml fragments of parameters and config2.inc is a file with xml fragments of more parameters. You just point to the file. Wantto take them out? Pull them out of the top of struts-config.xml - Original Message - From: Dan Miser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 10:07 AM Subject: Re: Extending ActionServlet Sure. Specify multliple config parameters in web.xml would be the first thing I would think of trying. I don't see why merging to one file is a big deal. Part of your build script (via Ant, perhaps) would be a step that would concat the files together.
Re: Extending ActionServlet
Hello Dan. If you have ANT, that is a good example. If not, than just make sure you DO NOT HAVE A COMPLETE XML DOCUMENT IN THE FRAGMENT. ex. The include file myInclude.inc would contain: !-- Properties -- property name=weblogic.install.dir value=/weblogic/ !-- End of properties -- Notice this IS NOT VALID XML. Thats because it will be shoved into the struts-config.xml which IS valid xml. Then you will declare these includes in the struts-config.xml file on the FIRST LINE of struts-config.xml like this: !DOCTYPE project [ !ENTITY config1 SYSTEM file:///config1.inc !ENTITY config2 SYSTEM file:///config2.inc ] Then you need to include these files (it acts like including). Where you want this to be inserted put it in like this config1; You may recognize this because it is an entity. You declared the entity at the top with !ENTITY config1 SYSTEM file:///config1.inc. Because of this declaration you can now refer to the external file as config1; inside struts-config.xml, and it will plug the whole contents of that file in place of config1; Get it? If not e-mail me back. - Original Message - From: Dan Miser [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Jonathan [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 1:14 PM Subject: Re: Extending ActionServlet I tried using entity references before with no luck. After reading this post, I just tried again, and it doesn't work. Do you have a working example of how to split the struts-config.xml from struts-example into modules (e.g. global, logon, subscription, registration, and admin)? I haven't looked at it, but I'm guessing the problem is in the Digester. Assuming entity references don't work, I outlined the reasoning for the approach I took in a previous message in this thread. -- Dan Miser http://www.distribucon.com - Original Message - From: Jonathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 10:35 AM Subject: Re: Extending ActionServlet I dont understand. Noone has to concat anything. You can include xml fragments in your master struts-config.xml like this: !DOCTYPE project [ !ENTITY header SYSTEM file:///config1.inc !ENTITY common SYSTEM file:///config2.inc ] where config1.inc is a file with xml fragments of parameters and config2.inc is a file with xml fragments of more parameters. You just point to the file. Wantto take them out? Pull them out of the top of struts-config.xml - Original Message - From: Dan Miser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 10:07 AM Subject: Re: Extending ActionServlet Sure. Specify multliple config parameters in web.xml would be the first thing I would think of trying. I don't see why merging to one file is a big deal. Part of your build script (via Ant, perhaps) would be a step that would concat the files together.
Re: Extending ActionServlet
I understand entity references in XML. That wasn't the problem. I'll start the ball rolling by showing you exactly what I did to struts-example, and you can tell me if this is what you did to get Struts to work in a module approach (using entity references). Here's my complete struts-config.xml: ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE struts-config PUBLIC -//Apache Software Foundation//DTD Struts Configuration 1.0//EN http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd; [!ENTITY global SYSTEM file://d:/tomcat/webapps/struts-example/WEB-INF/global.xml !ENTITY logonSYSTEM file://d:/tomcat/webapps/struts-example/WEB-INF/logon.xml !ENTITY registration SYSTEM file://d:/tomcat/webapps/struts-example/WEB-INF/registration.xml !ENTITY subscription SYSTEM file://d:/tomcat/webapps/struts-example/WEB-INF/subscription.xml !ENTITY adminSYSTEM file://d:/tomcat/webapps/struts-example/WEB-INF/admin.xml ] struts-config global; logon; registration; subscription; admin; /struts-config Here's the admin.xml file: action-mappings actionpath=/admin/addFormBean type=org.apache.struts.actions.AddFormBeanAction/ actionpath=/admin/addForward type=org.apache.struts.actions.AddForwardAction/ actionpath=/admin/addMapping type=org.apache.struts.actions.AddMappingAction/ actionpath=/admin/reload type=org.apache.struts.actions.ReloadAction/ actionpath=/admin/removeFormBean type=org.apache.struts.actions.RemoveFormBeanAction/ actionpath=/admin/removeForward type=org.apache.struts.actions.RemoveForwardAction/ actionpath=/admin/removeMapping type=org.apache.struts.actions.RemoveMappingAction/ /action-mappings The other xml files are similar to admin.xml, except they define form-beans, action-mappings, etc. that are specific to the area of functionality they are grouped in (e.g. logon, registration, etc.) Using this approach, struts-example will not work. Do you get different results? -- Dan Miser http://www.distribucon.com - Original Message - From: Jonathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 1:27 PM Subject: Re: Extending ActionServlet Hello Dan. If you have ANT, that is a good example. If not, than just make sure you DO NOT HAVE A COMPLETE XML DOCUMENT IN THE FRAGMENT. ex. The include file myInclude.inc would contain: !-- Properties -- property name=weblogic.install.dir value=/weblogic/ !-- End of properties -- Notice this IS NOT VALID XML. Thats because it will be shoved into the struts-config.xml which IS valid xml. Then you will declare these includes in the struts-config.xml file on the FIRST LINE of struts-config.xml like this: !DOCTYPE project [ !ENTITY config1 SYSTEM file:///config1.inc !ENTITY config2 SYSTEM file:///config2.inc ] Then you need to include these files (it acts like including). Where you want this to be inserted put it in like this config1; You may recognize this because it is an entity. You declared the entity at the top with !ENTITY config1 SYSTEM file:///config1.inc. Because of this declaration you can now refer to the external file as config1; inside struts-config.xml, and it will plug the whole contents of that file in place of config1; Get it? If not e-mail me back.
Re: Extending ActionServlet
I suspect that you may have problems pointing to the external file. You have file:// I have file:/// Also, I think it is better to use relative references - Original Message - From: Dan Miser [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Jonathan [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 3:15 PM Subject: Re: Extending ActionServlet I understand entity references in XML. That wasn't the problem. I'll start the ball rolling by showing you exactly what I did to struts-example, and you can tell me if this is what you did to get Struts to work in a module approach (using entity references). Here's my complete struts-config.xml: ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE struts-config PUBLIC -//Apache Software Foundation//DTD Struts Configuration 1.0//EN http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd; [!ENTITY global SYSTEM file://d:/tomcat/webapps/struts-example/WEB-INF/global.xml !ENTITY logonSYSTEM file://d:/tomcat/webapps/struts-example/WEB-INF/logon.xml !ENTITY registration SYSTEM file://d:/tomcat/webapps/struts-example/WEB-INF/registration.xml !ENTITY subscription SYSTEM file://d:/tomcat/webapps/struts-example/WEB-INF/subscription.xml !ENTITY adminSYSTEM file://d:/tomcat/webapps/struts-example/WEB-INF/admin.xml ] struts-config global; logon; registration; subscription; admin; /struts-config Here's the admin.xml file: action-mappings actionpath=/admin/addFormBean type=org.apache.struts.actions.AddFormBeanAction/ actionpath=/admin/addForward type=org.apache.struts.actions.AddForwardAction/ actionpath=/admin/addMapping type=org.apache.struts.actions.AddMappingAction/ actionpath=/admin/reload type=org.apache.struts.actions.ReloadAction/ actionpath=/admin/removeFormBean type=org.apache.struts.actions.RemoveFormBeanAction/ actionpath=/admin/removeForward type=org.apache.struts.actions.RemoveForwardAction/ actionpath=/admin/removeMapping type=org.apache.struts.actions.RemoveMappingAction/ /action-mappings The other xml files are similar to admin.xml, except they define form-beans, action-mappings, etc. that are specific to the area of functionality they are grouped in (e.g. logon, registration, etc.) Using this approach, struts-example will not work. Do you get different results? -- Dan Miser http://www.distribucon.com - Original Message - From: Jonathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 1:27 PM Subject: Re: Extending ActionServlet Hello Dan. If you have ANT, that is a good example. If not, than just make sure you DO NOT HAVE A COMPLETE XML DOCUMENT IN THE FRAGMENT. ex. The include file myInclude.inc would contain: !-- Properties -- property name=weblogic.install.dir value=/weblogic/ !-- End of properties -- Notice this IS NOT VALID XML. Thats because it will be shoved into the struts-config.xml which IS valid xml. Then you will declare these includes in the struts-config.xml file on the FIRST LINE of struts-config.xml like this: !DOCTYPE project [ !ENTITY config1 SYSTEM file:///config1.inc !ENTITY config2 SYSTEM file:///config2.inc ] Then you need to include these files (it acts like including). Where you want this to be inserted put it in like this config1; You may recognize this because it is an entity. You declared the entity at the top with !ENTITY config1 SYSTEM file:///config1.inc. Because of this declaration you can now refer to the external file as config1; inside struts-config.xml, and it will plug the whole contents of that file in place of config1; Get it? If not e-mail me back.
Re: Extending ActionServlet
I've tried the following: file://d:/tomcat/webapps/struts-example/WEB-INF/admin.xml file:///d:/tomcat/webapps/struts-example/WEB-INF/admin.xml admin.xml ./admin.xml All of them do not work with varying degrees of bad/good (exceptions on start up, to 503 errors when runnint the struts-example). The closest I can get is using the second URI. Have you tried this? Does it work? Do you get exceptions on start up? Can you access the entire site? -- Dan Miser http://www.distribucon.com - Original Message - From: Jonathan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 2:35 PM Subject: Re: Extending ActionServlet I suspect that you may have problems pointing to the external file. You have file:// I have file:/// Also, I think it is better to use relative references
Extending ActionServlet
Is there a way I can override the ActionServlet class to allow for multiple struts-config.xml files to be parsed for a single application? Our struts-config.xml file is getting rather large and it would be nice if we could split the struts-config.xml into multiple .xml files and have the ActionServlet, or a descendant, be able to parse all of the config files and store the action mappings. Thanks, Todd
Re: Extending ActionServlet
Hello TODD, Tuesday, June 19, 2001, 5:11:49 PM, you wrote: TH Is there a way I can override the ActionServlet class to allow for TH multiple struts-config.xml files to be parsed for a single TH application? Our struts-config.xml file is getting rather large TH and TH it would be nice if we could split the struts-config.xml into TH multiple .xml files and have the ActionServlet, or a descendant, TH be able to parse all of the config files and store the action TH mappings. You can extend ActionServelt, parse multiple struts-configs with Digester, store all stuff and work with it as with one big config. Each config must contains struts-config tag and store all stuff inside of it. And another way - you can write you own servlet to parse configs. Use ActionServlet as base for your configs loader, parse and store all mappings by the way, similar ActionServlet. -- Best regards, Olegmailto:[EMAIL PROTECTED]
RE: Extending ActionServlet
Title: RE: Extending ActionServlet I have done this and it works great. I load several struts-config.xml files into one mapping in the servlet. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 19, 2001 1:39 PM To: [EMAIL PROTECTED] Cc: JEFFERY WRIGHT Subject: Re: Extending ActionServlet On Tue, 19 Jun 2001, TODD HARNEY wrote: Is there a way I can override the ActionServlet class to allow for multiple struts-config.xml files to be parsed for a single application? Our struts-config.xml file is getting rather large and it would be nice if we could split the struts-config.xml into multiple .xml files and have the ActionServlet, or a descendant, be able to parse all of the config files and store the action mappings. Thanks, Todd I haven't actually tried this, but conceptually it should work -- could someone please try it and confirm to the list? The basic thought is that a single struts-config.xml file can actually have more than one struts-config section in it. Given, this you can logically divide your overall configuration into modules or whatever, and have each development group maintain their own stuff in their own struts-config.xml file. Then, when you deploy the app, part of the process would be simply combining all the struts-config.xml files into a single one (simple concatenation). It's worth a shot ... Craig
Re: Extending ActionServlet
On Tue, 19 Jun 2001, TODD HARNEY wrote: Is there a way I can override the ActionServlet class to allow for multiple struts-config.xml files to be parsed for a single application? Our struts-config.xml file is getting rather large and it would be nice if we could split the struts-config.xml into multiple .xml files and have the ActionServlet, or a descendant, be able to parse all of the config files and store the action mappings. Thanks, Todd This should be possible with plain XML: ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE struts-config PUBLIC -//Apache Software Foundation//DTD Struts Configuration 1.0//EN http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd; [ !ENTITY formsSYSTEM etc/forms.xml !ENTITY formsSYSTEM etc/forwards.xml !ENTITY mappings SYSTEM etc/mappings.xml ] struts-config forms; forwards; mappings; /struts-config where forms.xml contains your form-beans declarations, forwards.xml your global-forwards and mappings.xml your action-mappings. -- ...roland huss consol.de
Re: Extending ActionServlet
Craig, There are a few problems with that approach: 1. If you just have multiple struts-config elements, you end up not having a root element. That will cause the Digester to throw an exception when starting up. 2. So I added an element named root and put multiple struts-config elements under the root. The problem then becomes the code in the ActionServlet is looking for struts-config to be the root element. 3. Next, I extended the ActionServlet and overrode the initDigester method, changing the calls in the digester to reference */struts-config everywhere. That would work, but AddDataSourceRule is a private class, so I had to copy that from ActionServlet. After changing web.xml to use my new ActionServlet, I was able to get a module approach with a reorganized struts-config.xml from struts-example (I broke it up into global, login, registration, subscription, and admin). Worked beautifully. Of course, the struts-config.dtd would need to reflect this rework too. -- Dan Miser http://www.distribucon.com - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] I haven't actually tried this, but conceptually it should work -- could someone please try it and confirm to the list? The basic thought is that a single struts-config.xml file can actually have more than one struts-config section in it. Given, this you can logically divide your overall configuration into modules or whatever, and have each development group maintain their own stuff in their own struts-config.xml file. Then, when you deploy the app, part of the process would be simply combining all the struts-config.xml files into a single one (simple concatenation). It's worth a shot ... Craig
Re: Extending ActionServlet
On Tue, 19 Jun 2001, Dan Miser wrote: Craig, There are a few problems with that approach: 1. If you just have multiple struts-config elements, you end up not having a root element. That will cause the Digester to throw an exception when starting up. Argh, I knew there had to be some fly in the ointment ... 2. So I added an element named root and put multiple struts-config elements under the root. The problem then becomes the code in the ActionServlet is looking for struts-config to be the root element. 3. Next, I extended the ActionServlet and overrode the initDigester method, changing the calls in the digester to reference */struts-config everywhere. That would work, but AddDataSourceRule is a private class, so I had to copy that from ActionServlet. After changing web.xml to use my new ActionServlet, I was able to get a module approach with a reorganized struts-config.xml from struts-example (I broke it up into global, login, registration, subscription, and admin). Worked beautifully. Of course, the struts-config.dtd would need to reflect this rework too. That seems like an approach worth considering, since it doesn't break old struts-config.xml files, -- Dan Miser http://www.distribucon.com Craig - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] I haven't actually tried this, but conceptually it should work -- could someone please try it and confirm to the list? The basic thought is that a single struts-config.xml file can actually have more than one struts-config section in it. Given, this you can logically divide your overall configuration into modules or whatever, and have each development group maintain their own stuff in their own struts-config.xml file. Then, when you deploy the app, part of the process would be simply combining all the struts-config.xml files into a single one (simple concatenation). It's worth a shot ... Craig
Re: Extending ActionServlet
Why dont you do what ANT does? You can include an external reference inside the struts-config which acts like an include. Digester will parse struts-config.xml which will have external references to your external xml fragments. - Original Message - From: Oleg V Alexeev [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 19, 2001 12:48 PM Subject: Re: Extending ActionServlet Hello TODD, Tuesday, June 19, 2001, 5:11:49 PM, you wrote: TH Is there a way I can override the ActionServlet class to allow for TH multiple struts-config.xml files to be parsed for a single TH application? Our struts-config.xml file is getting rather large TH and TH it would be nice if we could split the struts-config.xml into TH multiple .xml files and have the ActionServlet, or a descendant, TH be able to parse all of the config files and store the action TH mappings. You can extend ActionServelt, parse multiple struts-configs with Digester, store all stuff and work with it as with one big config. Each config must contains struts-config tag and store all stuff inside of it. And another way - you can write you own servlet to parse configs. Use ActionServlet as base for your configs loader, parse and store all mappings by the way, similar ActionServlet. -- Best regards, Olegmailto:[EMAIL PROTECTED]
