DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-19 19:23 ---
AFAIK, this is done.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-12-22 06:29 ---
There are still a few items in the tests that will be need to be changed
but that will require a little thought, such as one test
extends ApplicationConfig and I would rather not directly
extend ModuleConfigImpl.java. So it will need to declare an 
ModuleConfig implementation using the factory added, then
place a facade over it.

-Rob

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-12-10 07:50 ---
> Also, can't we just rename the tests for ApplicationConfig to use 
ModuleConfig?

+0 !

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-12-10 06:27 ---
I've never understood AppException and no one has ever provided any explanation or 
docs for it so I 
wouldn't mind seeing it go.  Also, can't we just rename the tests for 
ApplicationConfig to use 
ModuleConfig?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-28 07:42 ---
I fixed over 100 references to 'application' there
are still more less obvious ones.
For instance struts-config.xml is a module config,
so seeing application config is a give away, but sometimes
just application is used.
Also example comments need to be changed.


Also to fully remove 'Application' 
o.a.s.u.AppException needs to be renamed to
ModuleException, or deprecated.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2002-11-25 02:23 ---
Unite tests need to be added. Currently there are tests for
ApplicationConfig, we need the same for ModuleConfig.
So who ever wants to tackle this, I won't be able to get
to it for a while.

-Rob

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-11-24 18:24 ---
I'm thinking we must have gotten all these by now, so I'm closing it pending contrary 
advice =:0)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-18 02:59 ---
Ok, let it be noted that I disagree with maintaining backwards compatibility between 
beta 
releases.  I believe this is too restrictive and forces us to create useless 
intermediate 
solutions.  The tag "beta" loses value when we start treating it as a contract with 
the user.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-18 02:38 ---
> Why doesn't PlugInPatch extend PlugIn? 
For Compatability. Eventually PlugIn will have
the new method signiture. The old method will be deleted.

>I don't see anything wrong with changing the PlugIn 
>I think we're going overboard on this.
> I don't like the idea of having these conversion artifacts hanging 
> around when we haven't even released the first version of plugins.

I waffled as to wheather we should break backwards compatability,
After Craig explained it was because of our Designation of Beta,
there better be a pretty good reason for breaking compatability.
We promised backwards compatability and I agree that for 1.1
that is the way it needs to be.

Once we go to the 1.2, 1.2.1 etc like Ant then we can adopt
an new policy.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-17 19:26 ---
Why doesn't PlugInPatch extend PlugIn?  In the javadoc you say that conversion time is 
2 minutes or 
less so why do we even need this interface?  I don't see anything wrong with changing 
the PlugIn 
interface directly as it hasn't been in a release yet.  Users will not be upset by 
this change 
because they know they're using beta software and the change is VERY minor.

I think we're 
going overboard on this.  I don't like the idea of having these conversion artifacts 
hanging 
around when we haven't even released the first version of plugins.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-09 16:55 ---
Finished !

Changes are backward compatable
with 1.1B2. ModuleConfig is used
exclusively internally.
Once 1.2 starts there needs to be
a Factory method. I didn't
add one since to construct 
an ApplicationConfig I needed to cast
a ModuleConfig to a ModuleConfigImpl.

There are doc cleanups to be done so
I am leaving this as open for now.
ie removing 'application'. 
There may be a few method in ActionServlet
that have the name 'application' in them etc...

-Rob

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-09 05:18 ---
I am adding the PlugInPatch interface to
give developers a chance to implement the
new init() signature. This does NOT replace
PlugIn, it basically tell's PlugIn developers
there is a method in PlugInPatch that will
eventually be made part of PlugIn interface 
and for now it is --optional--. 
See PlugIn's JavaDoc for more details.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-08 23:59 ---
All:

Feel free to jump in with the Renaming,
I'll be away this weekend.
The only snag I have hit is the action.PlugIn.
The Interface will change with the renaming,
and passing a ModuleConfig instead of
a ApplicationConfig. I doubt we want to rename
or deprecate this Interface. I guess we could just
add an additional method and deprecate 
the old init method, requiring plugin writers
to switch over to the new plugin initially by adding
a dummy init() method.

Updating the plugin itself was quick.
I changed the validator & tiles plugin to
use ModuleConfig Interface in under 5 minutes.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[David Graham]

I'm not opposed to the Impl naming if you don't have to type it in code or 
configure it.  The java socket classes use this convention but we're spared 
from seeing them.  In general, I believe Impl classes shouldn't be seen by 
general developers.

David






From: Robert Leland <[EMAIL PROTECTED]>
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
Subject: Re: DO NOT REPLY [Bug 14054] - Rename "Application" components to 
"Module"
Date: Mon, 04 Nov 2002 14:27:05 -0500

Subject:  Re: DO NOT REPLY [Bug 14054] - Rename "Application" components to 
"Module"
From: "David Graham" <[EMAIL PROTECTED]>
Date: 2002-11-04 18:04:41
[Download message RAW]

> +1 on the ModuleConfig interface (Struts needs more of these).
>  I'm not sure about StandardModuleConfigImpl though. > Where will the 
user see this *Impl class if anywhere?
> If the user never has to write this then I suggest ModuleConfigImpl. > 
If they have to write it somewhere then drop the "Impl"
> part and use StandardModuleConfig or StrutsModuleConfig.


'ModuleConfigImpl' would be +1. The 'Impl' was patterened after what we do 
here
at my Job and also what commons-logging, commons-pool do for naming 
implementations
and interfaces.

If a --user-- is defined as struts-user mailing list, yes they shouldn't 
see the Impl classes. Neither, would
most of the Struts internal classes. I didn't want to overdesign but did 
want to reserve
the name 'ModuleConfig' for the general concept.


> Dave

-Rob



--
To unsubscribe, e-mail:   
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: 
<mailto:struts-dev-help@;jakarta.apache.org>


_
Get faster connections -- switch to MSN Internet Access! 
http://resourcecenter.msn.com/access/plans/default.asp


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

Re: DO NOT REPLY [Bug 14054] - Rename "Application" components to"Module"

[Robert Leland]

Subject:  Re: DO NOT REPLY [Bug 14054] - Rename "Application" components 
to "Module"
From: "David Graham" <[EMAIL PROTECTED]>
Date: 2002-11-04 18:04:41
[Download message RAW]

> +1 on the ModuleConfig interface (Struts needs more of these).
>  I'm not sure about StandardModuleConfigImpl though. 
> Where will the user see this *Impl class if anywhere?
> If the user never has to write this then I suggest ModuleConfigImpl. 
> If they have to write it somewhere then drop the "Impl"
> part and use StandardModuleConfig or StrutsModuleConfig.


'ModuleConfigImpl' would be +1. The 'Impl' was patterened after what we 
do here
at my Job and also what commons-logging, commons-pool do for naming 
implementations
and interfaces.

If a --user-- is defined as struts-user mailing list, yes they shouldn't 
see the Impl classes. Neither, would
most of the Struts internal classes. I didn't want to overdesign but did 
want to reserve
the name 'ModuleConfig' for the general concept.


> Dave

-Rob



--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

Re: DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[David Graham]

+1 on the ModuleConfig interface (Struts needs more of these).  I'm not sure 
about StandardModuleConfigImpl though.  Where will the user see this *Impl 
class if anywhere?  If the user never has to write this then I suggest 
ModuleConfigImpl.  If they have to write it somewhere then drop the "Impl" 
part and use StandardModuleConfig or StrutsModuleConfig.

Dave




From: [EMAIL PROTECTED]
Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 14054]  - Rename "Application" components to 
"Module"
Date: 4 Nov 2002 17:41:18 -

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 17:41 
---
So how do we get this process started again ?
I apologize if any comments I made about the the
 ActionMapping->ActionConfig were hasty, judgemental, or
 offended anyone.

My concern right now if to get this process going again.
Since the deprecated code will only exist through Struts 1.1
I would be a +1 on --whatever-- method we choose.
Should we call for a consensis vote ?

I do believe we should provide a deprecation path for users,
Whatever method we use, providng a deprecation path will
only cost us about 10 minutes more than a straight rename.

I would like to make one more suggestion through, and that is to
go ahead and use an interface at the back end of the process
ModuleConfig   - Interface
^
|
  StandardModuleConfigImpl  - Existing ApplicationConfig code
^
|
 ApplicationConfig  - Deprecated Method name.

Delay adding a FactoryMethod for 1.1.
Otherwise for 1.1->1.2 we might go through this renaming again,
when/if other ModuleConfig schemes are implemented.
By doing an interface now we reserve the name ModuleConfig for
the concept it represents and not the implementation.

--
To unsubscribe, e-mail:   
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: 
<mailto:struts-dev-help@;jakarta.apache.org>


_
Choose an Internet access plan right for you -- try MSN! 
http://resourcecenter.msn.com/access/plans/default.asp


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 17:41 ---
So how do we get this process started again ?
I apologize if any comments I made about the the 
 ActionMapping->ActionConfig were hasty, judgemental, or
 offended anyone.

My concern right now if to get this process going again.
Since the deprecated code will only exist through Struts 1.1
I would be a +1 on --whatever-- method we choose.
Should we call for a consensis vote ?

I do believe we should provide a deprecation path for users,
Whatever method we use, providng a deprecation path will 
only cost us about 10 minutes more than a straight rename. 

I would like to make one more suggestion through, and that is to 
go ahead and use an interface at the back end of the process
ModuleConfig   - Interface 
^
|
  StandardModuleConfigImpl  - Existing ApplicationConfig code
^
|
 ApplicationConfig  - Deprecated Method name.

Delay adding a FactoryMethod for 1.1.
Otherwise for 1.1->1.2 we might go through this renaming again,
when/if other ModuleConfig schemes are implemented.
By doing an interface now we reserve the name ModuleConfig for
the concept it represents and not the implementation.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-04 11:32 ---
Personally, I'm very impressed by the attention to detail here. But I just wanted to 
mention that 
Struts 1.1 is in BETA. We have betas so we can shake-out issues like this and fix them 
before we 
promote the codebase to a release. I really don't know how many people, if any, are 
referring to 
these objects directly. If they are, the problem would be very easy for them to fix by 
renaming 
their own references. At this level, we are working with other advanced developers and 
can expect 
them to do some of their own leg work. I agree that changing how the new config 
package works at this 
point would be rude, but I think simply renaming things doesn't have to be a big deal 
between beta 
releases. I would agree that this discussion would be on task if this were Struts 1.2 
and we were 
renaming the component after the code was formally released. But I truly do not think 
any one 
outside the team will criticize us for just renaming this component now and moving 
forward. When 
it is just as easy for us to deprecate changes between betas, sure, lets go the extra 
yard and do the 
polite thing. But when it stops being simple, we should cut to the chase and play the 
beta card.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-11-01 13:37 ---
I compared the 1.1B2 code to the 1.1 current as of Nov 1.
There are no new methods involving ApplicationConfig
since B2. Except the two that are marked @since Struts 1.1b3
in RequestUtils.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-30 17:23 ---
How about ApplicationConfig ActionConfig.getApplicationConfig() ?

We still need to create a ApplicationConfig object, we aren't
allowed to change the return type if we are to
support recompile compatability.

Since the method is public we have to assume that other people
could be extending it, or using it in some way.
It would be nice if Java had the equalivent of a friend class.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-30 16:06 ---
Why can't you change ActionConfig.setApplicationConfig(ApplicationConfig) to 

ActionConfig.setApplicationConfig(ModuleConfig) and have it 
call

ActionConfig.setModuleConfig(ModuleConfig)?

Because all ApplicationConfig 
objects are children of ModuleConfig the calls will still work (you can pass 
ApplicationConfig 
objects into methods taking ModuleConfig).

I haven't looked too much at the code but I still 
don't see any reason you can't store ModuleConfig objects in the request instead of 
ApplicationConfig.  Once ApplicationConfig is a child of ModuleConfig it doesn't 
matter which 
one we put in the request.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-30 15:32 ---
The problem comes when constructing the new ModuleConfig

in the constructor method there is a 
ActionConfig.setApplicationConfig(ApplicationConfig)
which is public, so it MUST be supported but deprecated.

If we created a ActionConfig.setModuleConfig(ModuleConfig)
instead we would still need to support
ActionConfig.setApplicationConfig(ApplicationConfig)

So how do we do that ?

Composition will work but inheritance,superclass, doesn't.

Also we only want to store a ModuleConfig in the request scope,
from which we can also create a ApplicationConfig.
If we continued to store an ApplicationConfig in the request instead
then that would probably force struts internally to continue to use
the ApplicationConfig, which defeats the whole purpose of
changing the Class/method names in the first place.

Using inheritance there is no way, I know of to,
to make a ApplicationConfig from a
ModuleConfig, w/o copying or cloning pointers or datastructures,
yuck.

-Rob

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-30 15:14 ---
I don't understand why the inheritance idea won't work.  Why do you want to make an 
ApplicationConfig object from a ModuleConfig and vice versa?  If you make ModuleConfig 
the 
parent then people subclassing ApplicationConfig can still pass that into methods that 
take a 
ModuleConfig object.

If that works, you can just move the protected fields into 
ModuleConfig and people won't know the difference.  I agree that we need to use 
interfaces but not 
for 1.1.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-30 14:19 ---
The superclass approach isn't
a good approach, since it doesn't let me create
ApplicationConfig objects from ModuleConfig.
I looked through martin Fowlers "Refactoring" book,
but it didn't help.
The best way to go is using composition, the original plan,
which will do this.
It lets a ModuleConfig object be created from a ApplicationConfig object and
a ApplicationConfig object from a ModuleConfig object.

However, I am asking for 
--- ONE BIG EXCEPTION ---
to the deprecation rule.

To use composition I would like to delete the 
protected fields in the ApplicationConfig object.
I see now why Craig likes to make fields private
first and if someone has a good reason why not!
Also I would like to make all the fields in 
ModuleConfig private ! If we ever go to other schemes
for implementing ModuleConfigs this will make life
much easier. We may want to use interfaces then (2.0)
and going from a class with all private fields will be much
easier !

This apporach will even allow all the protected fields in
ActionConfig and other classes to remain unchanged.

Is there a better suggestion, other than waiting till 2.0 ;-) !

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-30 03:09 ---
P.S.

I have also checked out the struts_1_1_b2 branch,
any method that appeared after that release will be simply replaced
and not deprecated. Again since ApplicationConfig derives from
MethodConfig code should still compile in the case of
method signature changes.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-30 02:26 ---

Ok I have spent a few hours looking at it all.

The level of compatability I propose will require a recompile.
Also all public and protected classes methods will be deprecated.
private methods will have their signature changed w/o
a deprecation, I would love to do that for protected also 
but we promised.

I propose to create a superclass for ApplicationConfig
named ModuleConfig. It will contain all of methods
and attributes. The result will be that ApplicationConfig
is an empty shell. This will allow the storing of a
ApplicationConfig, not ModuleConfig as before in the session.
This is the only way I can think of to store a single object and still use
it as both a ApplicationConfig and ModuleConfig.

This will allow a user to pass a ApplicationConfig
to a method that takes a ModuleConfig.

This is going to take more work for compatability than I thought.
With one button from IntelliJ I can rename classes, but this will take
a little more effort.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-30 00:37 ---
Deal.

My first plan is to make ApplicationConfig deprecated
and have it call the ModuleConfig class, which I'll checkin.
Then change the various getAppConfig() methods
in several classes. Test that then checkin.
That will be the easy part the next part will
be to find all reference to 'app' or 'application'
then determine if they refer to modules or not.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-29 22:46 ---
I'd be happy to help with getting these switched and tested ASAP.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-29 22:42 ---
You get a +1 from me.  Just to be clear, deprecate existing classes/methods and add 
new ones with 
"module", right?  Once I get my development environment functioning again I can help 
out.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 14054] - Rename "Application" components to "Module"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14054

Rename "Application" components to "Module"





--- Additional Comments From [EMAIL PROTECTED]  2002-10-29 21:37 ---
So who wants to give this a shot ?
There are 618 occurances of 'Application'
The first and easiest is the deprecation
of ApplictionConfig and replacing it by
ModuleConfig.

Thera are also such items as
public static final String APPLICATION_KEY =
"org.apache.struts.action.APPLICATION";
In this case would be really deprectate
APPLICATION_KEY or just rename it ?

I am game to make the first round of changes ie
ApplicationConfig -> ModuleConfig throughout the
Struts code base. I imagine we would have to
do this a few times to get other references to
application out, which can be confused with
application scope. 

Do I get a +1 for this limited change tonight,
deprecation+replacing ?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: