You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2006/03/20 20:33:22 UTC

DO NOT REPLY [Bug 39040] New: - Refactor Struts initialization to ServletContextListener

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040

           Summary: Refactor Struts initialization to ServletContextListener
           Product: Struts
           Version: Nightly Build
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Action
        AssignedTo: dev@struts.apache.org
        ReportedBy: Joe@Germuska.com


Opening an enhancement ticket in order to generate some discussion and possibly
give a volunteer an idea for a project :-)

As part of migrating to Action 2, I thought that it might be a good idea to try
to have Struts configured by a ServletContextListener instead of concentrating
that initialization in the servlet.  The main idea would be that this would
steer any compatibility solution towards dispatching requests using a single
mechanism (presumably a future version of WebWork's FilterDispatcher) which
could set up a better framework for sharing and blending than simply leaving a
Struts 1.x ActionServlet in your config until you've factored out all of your
actions.

There would be a lot of tasks to this, but it seems that the first would be
simply factoring the initialization code out of ActionServlet in the Struts 1.x
line so that its basic functionality can be verified in the field.  

Comments?  Volunteers?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040


Joe@Germuska.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Additional Comments From Joe@Germuska.com  2006-03-25 21:55 -------
Actually, it just seems to me like Struts shouldn't acknowledge any more
awareness of the Servlet API than absolutely necessary.  This would help use
with portlets, but may also make testing easier.

I'm looking into this some more and here's the rough outline:  a
"StrutsConfigurator" interface that has two methods:

public void initialize(Map application);
public void destroy(Map application);

then the ServletContextListener class would make a configurator and wrap the
servlet context in a map and pass it to the configurator.  I suppose somehow
I'll also have to pass in information about where the config files are...

Is there any objection to me wholesale lifting
com.opensymphony.webwork.dispatcher.ApplicationMap to perform the
ServletContext-to-Map adaptation?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





------- Additional Comments From Joe@Germuska.com  2006-03-20 22:32 -------
I think we're on the same page -- I figured that an intermediate/shared
"ConfigUtil" would be used by both ActionServlet and this theoretical listener.
 I hadn't thought specifically about it being a third class.  

I love the idea of minimizing/controlling dependencies upon the Servlet API, but
that could be more work than it's worth, especially since XWork provides that
for Struts 2.x -- but maybe you are just talking about having a straightforward
way to establish a test environment, perhaps with Mock implementations of
Servlet classes?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





------- Additional Comments From Joe@Germuska.com  2006-03-30 13:56 -------
As Hubert pointed out, there are already ways to do augment the initialization
process without getting involved in this specific listener.  That said, I would
probably do something to make the chain extensible/replaceable.

My intention, again, is to try to start down the path of integrating Struts 1.x
compatibility in SAF 2.x.  My idea (more of a gut feeling than a thoroughly
reasoned stance) is that integration is better than just dropping in
ActionServlet and making things go in parallel.  Also, when I've tried to do
things with the init process in ActionServlet before, it has often been awkward
to work in there, so I think this will just help clarify what goes on there.

If there are other positive side effects, like testing, that's great.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





------- Additional Comments From john.r.fallows@gmail.com  2006-03-30 00:41 -------
(In reply to comment #6)
> I started into some of this on Saturday, but then ran out of time.  I have a
> path which I think will work out; it involves using a commons chain to string
> together configuration steps, more or less one for each "init" method in
> ActionServlet.  At the end, it would set something into application scope so
> that ActionServlet could be changed to look for that and skip configuration when
> it was present.
> 
> It will be a fair bit of work to finish all of this, so I'd kind of like to get
> a bit of feedback before I slog through it all (including whether anyone besides
> Niall thinks its worthwhile!).

This sounds great.  Perhaps an optional command could be included in the
initialization chain to allow Struts developers to provide their own one-time
initialization logic.  For example, registration of custom commons-beanutils
Converters for application-specific object types.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





------- Additional Comments From niallp@apache.org  2006-03-20 19:47 -------
I think this is a good idea - it may be what you intended, but I'd like to 
clarify what you suggest. IMO the refactoring should be considered in two 
parts:

1) Refactor struts initialization code out of the servlet environment 
altogether - so its not tied either to either a Servlet or 
ServletContextListener. As well as achieving the goals you envisage I would 
hope this would make it easier to test the initialization code and could be 
used as part of a test framework for testing the whole of the RequestProcessor 
command chain.

2) Provide a ServletContextListener implementation of the initialization code.

I haven't actually looked at how useful/doable 1) would be - but I think it 
would make a good starting point for consideration.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





------- Additional Comments From niallp@apache.org  2006-03-21 00:02 -------
I haven't put any effort into looking at the best way to achieve this or whats 
fully required, although from memory the interaction with the servlet 
environment is minimal - mostly getting/setting ServletContext attributes? If 
that is the case then maybe a Map representation of the ServletContext 
attributes would mostly do - which we already have as part of the request 
processing and its context.

If it does turn out to be too much work, then yes just a dependency on the 
ServletContext, which can easily be mocked would be next best.

Really I was just trying to throw out some ideas for consideration for anyone 
who decided to pick this up.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





------- Additional Comments From Joe@Germuska.com  2006-03-27 22:19 -------
I started into some of this on Saturday, but then ran out of time.  I have a
path which I think will work out; it involves using a commons chain to string
together configuration steps, more or less one for each "init" method in
ActionServlet.  At the end, it would set something into application scope so
that ActionServlet could be changed to look for that and skip configuration when
it was present.

It will be a fair bit of work to finish all of this, so I'd kind of like to get
a bit of feedback before I slog through it all (including whether anyone besides
Niall thinks its worthwhile!).  Since these are mostly new files, I'll attach a
tarball of what I have so far -- note that this is very much draft code.

I still haven't decided how to bootstrap the chain config itself, but that
shouldn't be a huge deal.  

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





------- Additional Comments From Joe@Germuska.com  2006-03-27 22:21 -------
Created an attachment (id=17996)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17996&action=view)
Early draft of work to extract Struts initialization from ActionServlet
(gzipped tar file)


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





------- Additional Comments From martinc@apache.org  2006-03-21 00:43 -------
When you refer to removing the dependency on the Servlet API, I'm assuming this
is for the purpose of supporting portlets? In that case, creating an interface
that has the common methods would do the trick. Here's what you need from the
Portlet 1.0 spec:

"PLT.10.3.1 Correspondence between ServletContext and PortletContext methods

The following methods of the PortletContext should provide the same
functionality as the methods of the ServletContext of similar name:
getAttribute, getAttributeNames, getInitParameter, getInitParameterNames,
getMimeType, getRealPath, getResource, getResourcePaths, getResourceAsStream,
log, removeAttribute and setAttribute."

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


DO NOT REPLY [Bug 39040] - Refactor Struts initialization to ServletContextListener

Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39040>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39040





------- Additional Comments From hrabago@apache.org  2006-03-30 00:47 -------
(In reply to comment #8)
> Perhaps an optional command could be included in the
> initialization chain to allow Struts developers to provide their own one-time
> initialization logic.  

Struts plugins already provide this functionality.  In containers that support 
them, ServletContextListeners are another option [1].

Hubert

[1] http://marc.theaimsgroup.com/?l=struts-user&m=110840823606930&w=2


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org