Hello Gregor an Walden,

thank you very much for your comments!
I gave up my plan yesterday. I tried to call one module from the other
by JSNI native calls, but I ran into various problems so that I
finally gave up. What I am now doing is inheriting the generic module
in the customer specific module. Then I deploy it in one WAR file.
As Walden said, I am avoiding incompatability issues doing it that
way.

Regards,
Christoph

On 23 Sep., 19:56, gregor <[EMAIL PROTECTED]> wrote:
> Hi Christoph,
>
> To add a little to walden's comments, Tomcat (or JBoss/a.n.other app
> server) will allocate a separate class loader to each web application
> (WAR) deployed. So if you deploy two WAR's they can both access
> classes declared in their parent's class loader (normally this is the
> container's own class loader), but they canot see each others classes.
>
> You can call a servlet in web app A from a servlet web app B, but that
> invokes the whole HTTP/TCP/IP stack: your server is effectively
> calling itself, so this may work fine in development but in the field
> it will bring your servers to their knees.
>
> What you may be able to do (depending on your use case) is to deploy
> your back end as a RAR (Resource ARchive, the idea being the services,
> and their classes/interfaces, are available to all WAR's and EAR's
> running on the app server, i.e. the classes are loaded by the app
> server's main class loader ): this would mean your GWT web apps would
> deployable independently from your back end (potentially).
>
> regards
> gregor
>
> On Sep 23, 2:07 pm, walden <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > I think the answer is 'no', although there may be work in the
> > pipelines to address late binding among GWT modules (I don't track
> > that).
>
> > However, from a configuration management POV, what you are proposing
> > makes no sense because you will need to do integration testing of the
> > new configuration consisting of an unmodified module A and a modified
> > module B.  If you don't do that testing, then your production
> > environment will be in an unkown configuration (i.e., technically
> > broken).  If you do do that testing, then you will have had
> > opportunity to package the entire new configuration, which might as
> > well be a monolilthic build as not.
>
> > So where's the advantage?
>
> > Walden
>
> > On Sep 23, 4:27 am, cschoett <[EMAIL PROTECTED]> wrote:
>
> > > Hello,
>
> > > i have a question related to packaging a larger business application.
> > > I am building a GWT application that contains two parts, a generic
> > > part and a customer specific part that will be changed for every
> > > customer. Both parts depend on each other and shall be integrated into
> > > one big application.
> > > A major requirement is that the generic part shall be developed and
> > > deployable independently from the customer specific part. If we for
> > > example discover a bug or add features to the generic part we want to
> > > deliver an archive (WAR file) to the customer without touching the
> > > customer specific part (in some cases we even won't have access to the
> > > customer specific part.
>
> > > As far as I know so far, it is possible to create two seperate modules
> > > where the customer specific modules inherits the generic module. So I
> > > have an idependance at source level. But when I compile the customer
> > > specific module, both modules are compiled into one folder. Is it
> > > possible to separate the two modules and package them into separate
> > > WAR files? Is there any other way to integrate two modules so that the
> > > can be developed and deployed independently?
>
> > > Many thanks in advance.
>
> > > Kind regards,
> > > Christoph
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to