Pros and cons of multi module applications

[Mikolaj Rydzewski <mi...@ceti.pl>]

Hi,

I've got three similiar web applications (struts 1.3). They are a part 
of one service, with single-sign-on enabled. It works fine. I wonder how 
difficult would it be to convert them into one, module aware application.

There are session form-beans used. Probably with the same names. Would 
it be a problem?

How does modules work with tiles? Will I have to modify forwards' paths 
and tiles definitions' paths to work with modules?

I know the rule: if it works don't fix it ;-) Unfortunately there's one 
common module, shared by all the applications and that's the reason I 
want to join them.

-- 
Mikolaj Rydzewski <mi...@ceti.pl>

Re: Pros and cons of multi module applications

[Ted Husted <hu...@apache.org>]

It's not difficult to migrate. We did the same with three of our
appilcations, by combining them in to the single struts-examples
application.

The session would be shared, so beans with the same name would be a
problem, if they shouldn't overwrite each other.

Tiles should work just fine with modules.

-Ted.

On 11/22/06, Mikolaj Rydzewski <mi...@ceti.pl> wrote:
> Hi,
>
> I've got three similiar web applications (struts 1.3). They are a part
> of one service, with single-sign-on enabled. It works fine. I wonder how
> difficult would it be to convert them into one, module aware application.
>
> There are session form-beans used. Probably with the same names. Would
> it be a problem?
>
> How does modules work with tiles? Will I have to modify forwards' paths
> and tiles definitions' paths to work with modules?
>
> I know the rule: if it works don't fix it ;-) Unfortunately there's one
> common module, shared by all the applications and that's the reason I
> want to join them.
>
> --
> Mikolaj Rydzewski <mi...@ceti.pl>
>

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