Communicating between webapps

[Darryl Pentz]

I have an issue where webapp A needs to let webapp B know about an event, and then return a response to webapp B's processing of that event to the browser. So basically I need to communicate between webapps in the same container.

I have not found a no-brainer solution to this as yet. The one I have tried is making a localhost HTTP call which I find to be rather expensive, given that it requires creating a socket connection to the same container.

I also just encountered the 'crosscontext' attribute in the <context.../> block and was wondering whether that could serve any purpose.

Does anybody know of any tried and trusted ways of communicating between webapps in Tomcat?

Thanks,
Darryl Pentz





---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Leon Rosenberg]

RMI, CORBA or (worst choice) SOAP.

Everything else, like using libs in shared/server folders etc are hacks :-)

Leon

Post by Darryl Pentz
I have an issue where webapp A needs to let webapp B know about an event, and then return a response to webapp B's processing of that event to the browser. So basically I need to communicate between webapps in the same container.
I have not found a no-brainer solution to this as yet. The one I have tried is making a localhost HTTP call which I find to be rather expensive, given that it requires creating a socket connection to the same container.
I also just encountered the 'crosscontext' attribute in the <context.../> block and was wondering whether that could serve any purpose.
Does anybody know of any tried and trusted ways of communicating between webapps in Tomcat?
Thanks,
Darryl Pentz
---------------------------------------------------------------------

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[André Warnier]

Post by Leon Rosenberg
RMI, CORBA or (worst choice) SOAP.
Everything else, like using libs in shared/server folders etc are hacks :-)
Leon

Post by Darryl Pentz
I have an issue where webapp A needs to let webapp B know about an event, and then return a response to webapp B's processing of that event to the browser. So basically I need to communicate between webapps in the same container.
I have not found a no-brainer solution to this as yet. The one I have tried is making a localhost HTTP call which I find to be rather expensive, given that it requires creating a socket connection to the same container.
I also just encountered the 'crosscontext' attribute in the <context.../> block and was wondering whether that could serve any purpose.
Does anybody know of any tried and trusted ways of communicating between webapps in Tomcat?

Maybe hacks, but why not use them if they are easier, faster, and have a
smaller memory footprint ?
Not being very good at either Java or Tomcat, I'll submit the following
ideas, and watch for comments :

Depending on what exactly you need to pass as information, why not just
the fact of whether a given "flag" file exists in a directory under
catalina.base ? I know that this sounds quite pedestrian, but
considering that a webserver already makes zillions of file accesses
anyway, I don't think the overhead of a few more would matter.

Or, if both webapps already use some common database, a record in ditto
database. That is probably more flexible and more reliable re locking.

Or, a webapp with the appropriate permissions can set/reset/read a
system property, and these should be shared by all apps under the same
JVM instance, no ? what I don't know is if set/reset of a system
property is "atomic".


---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Peter Crowther]

Post by André Warnier
Maybe hacks, but why not use them if they are easier, faster,
and have a smaller memory footprint ?

Because they can be harder to maintain. Note *can be* - it depends on the developers and admins.

Post by André Warnier
Not being very good at either Java or Tomcat, I'll submit the
following
Depending on what exactly you need to pass as information,
why not just
the fact of whether a given "flag" file exists in a directory under
catalina.base ? I know that this sounds quite pedestrian, but
considering that a webserver already makes zillions of file accesses
anyway, I don't think the overhead of a few more would matter.
Or, if both webapps already use some common database, a
record in ditto
database. That is probably more flexible and more reliable re locking.
Or, a webapp with the appropriate permissions can set/reset/read a
system property, and these should be shared by all apps under the same
JVM instance, no ? what I don't know is if set/reset of a system
property is "atomic".

I think the OP wanted webapp A to call webapp B and return the result from B, via A, to the user. None of these cause A to invoke code in B, though they're all solutions to the problem of A informing B that something has changed.

- Peter

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Mikolaj Rydzewski]

Post by Darryl Pentz
I have not found a no-brainer solution to this as yet. The one I have tried is making a localhost HTTP call which I find to be rather expensive, given that it requires creating a socket connection to the same container.

Have you actualy measured that additional local HTTP call is to
expensive for you? It's the simplest way. Go with KISS rule ;-)

You can also use JMX, RMI, etc.

[Leon Rosenberg]

Post by Darryl Pentz
I have not found a no-brainer solution to this as yet. The one I have
tried is making a localhost HTTP call which I find to be rather expensive,
given that it requires creating a socket connection to the same container.

Have you actualy measured that additional local HTTP call is to expensive
for you? It's the simplest way. Go with KISS rule ;-)

How is that KISS?
You need additional lib (commons httpclient), you need special
servlet/action/jsp on B-side, you probably need to start threads, you
need to monitor those on A side, and and and...

Or you just add the words " extends Remote" to your service interface
and start the RMIRegistry.

which is KISSier? :-)

Leon

--
---------------------------------------------------------------------

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Mikolaj Rydzewski]

Post by Leon Rosenberg
You need additional lib (commons httpclient), you need special
servlet/action/jsp on B-side, you probably need to start threads, you
need to monitor those on A side, and and and...

One can use HttpURLConnection. There're probably some actions/jsps
already in the webapp, one more makes no harm.

Anyway, yes, it's maybe more work than to extend Remote. But IMO gives
you more flexibility than RMI. It's easier and more common to allow HTTP
trafic through firewalls, than RMI traffic.

We don't know what kind of infromation Daryl wants to exchange. Maybe
it's worth to go with RMI, maybe it isn't.

[André Warnier]

Post by Mikolaj Rydzewski

Post by Leon Rosenberg
You need additional lib (commons httpclient), you need special
servlet/action/jsp on B-side, you probably need to start threads, you
need to monitor those on A side, and and and...

One can use HttpURLConnection. There're probably some actions/jsps
already in the webapp, one more makes no harm.
Anyway, yes, it's maybe more work than to extend Remote. But IMO gives
you more flexibility than RMI. It's easier and more common to allow HTTP
trafic through firewalls, than RMI traffic.
We don't know what kind of infromation Daryl wants to exchange. Maybe
it's worth to go with RMI, maybe it isn't.

But we do know that the issue is to exchange information betweeb appA
and appB on the same server, so firewall and comms issue should not be
relevant here.
What we do not know (yet) is the platform, Tomcat version etc, but I am
sure Daryl will tell us if it is relevant.

Another thing that I personally don't know is what RMI exactly is or
does (yes, I'm a definite Java amateur). Rightly or wrongly, what I
don't know tends to inspire me with caution. For example, I am cautious
about statements (related to Java) like 'you just need to add " extends
Remote" to your ... to .. ', when I don't know how many extra classes
and MB and cpu cycles this innocent-looking attribute adds to one
instance of one's application.
But I am curious and willing to be taught. Without losing sight of the
original OP question of course.




---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Darryl Pentz]

In my case, webapp A needs to let webapp B know that an event has occurred ... webapp B then does something based on that event, and the result of that action is relevant to webapp A.

I did in fact use HttpURLConnection because the original HttpClient class (Commons I think) was a memory pig and just turned out to be way too inefficient. I don't involve any JSP's. Webapp B has a simple EventServlet that gets the request from webapp B.

I guess in answer to your KISS comment, the thought of being able to do something inside the VM, as opposed to the overhead of opening up a socket and doing the comms, just seems heavy and I do seem to have varying performance with my HTTP approach that I can't seem to isolate. Admittedly I am using Groovy on the webappA side, but that shouldn't impact performance to the extent I'm seeing.

I appreciate the suggestions from all so far. It does seem like at least there isn't a 'no-brainer' approach, as in "of course stupid, why don't you just do X - everybody else does". It sounds like each solution has its clear pros and cons which must be weighed up in light of my particular environment and requirements.

- Darryl



----- Original Message ----
From: Mikolaj Rydzewski <***@ceti.pl>
To: Tomcat Users List <***@tomcat.apache.org>
Sent: Wednesday, October 8, 2008 12:54:10 PM
Subject: Re: Communicating between webapps

Post by Leon Rosenberg
You need additional lib (commons httpclient), you need special
servlet/action/jsp on B-side, you probably need to start threads, you
need to monitor those on A side, and and and...

One can use HttpURLConnection. There're probably some actions/jsps
already in the webapp, one more makes no harm.

Anyway, yes, it's maybe more work than to extend Remote. But IMO gives
you more flexibility than RMI. It's easier and more common to allow HTTP
trafic through firewalls, than RMI traffic.

We don't know what kind of infromation Daryl wants to exchange. Maybe
it's worth to go with RMI, maybe it isn't.
--
Mikolaj Rydzewski <***@ceti.pl>


---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org




---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Mikolaj Rydzewski]

Post by Darryl Pentz
I appreciate the suggestions from all so far. It does seem like at least there isn't a 'no-brainer' approach, as in "of course stupid, why don't you just do X - everybody else does". It sounds like each solution has its clear pros and cons which must be weighed up in light of my particular environment and requirements.

If you're not afraid of using more MBs of jars you can consider using
openjms. IMO it's the most 'elegant' solution. I guess that asynchronous
approach is ok for you.

[Christopher Schultz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Darryl,

Post by Darryl Pentz
In my case, webapp A needs to let webapp B know that an event has
occurred ... webapp B then does something based on that event, and
the result of that action is relevant to webapp A.

What are your options for simply moving the "webapp B" processing into
"webapp A"? Do you have any?

I think it might help if we had an example of what you're actually
doing. If you can't give us details, how about generalities like "I
might have to invoke a JSP" or "I have a specific servet that needs to
be called" or "this isn't really HTTP at all".

What I find to be the "KISSiest" (thanks Leon) approach is for your
application to "drink its own Kool-Aid" by using the same interface that
the rest of the world would see for whatever application B (which almost
sounds like a service) would see.

I hope that stimulates some discussion. With this crowd, if no doubt will.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjvsCUACgkQ9CaO5/Lv0PBckgCePZEUkp8Q7fpmwbALtmp02lXK
sVUAoKR/ivY54UGpe6mycTDXTdH6zNtz
=ng4l
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Brantley Hobbs]

Post by Darryl Pentz
I have an issue where webapp A needs to let webapp B know about an event, and then return a response to webapp B's processing of that event to the browser. So basically I need to communicate between webapps in the same container.
I have not found a no-brainer solution to this as yet. The one I have tried is making a localhost HTTP call which I find to be rather expensive, given that it requires creating a socket connection to the same container.
I also just encountered the 'crosscontext' attribute in the <context.../> block and was wondering whether that could serve any purpose.
Does anybody know of any tried and trusted ways of communicating between webapps in Tomcat?
Thanks,
Darryl Pentz

If you think that this thing will scale at all, steer clear of any
shared resources like JVM properties or magic files. It could be that
in the future the apps won't run even in the same network, much less the
same JVM. This is a classic SOA problem.

My $0.02:
If you're not transporting binary, might I suggest JSON? It's a whole
lot less painful to configure (no XML or schemas), and there are Java
JSON clients (jabsorb has one) that make it a snap to integrate into
your project. It just works like magic. We've been using it with our
projects for months now and are quite happy with it, both in terms of
performance and ease-of-use. JSON does use HTTP transport, so if you're
determined not to use HTTP, then it may not be for you.

Brantley

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[André Warnier]

Post by Darryl Pentz
I have an issue where webapp A needs to let webapp B know about an
event, and then return a response to webapp B's processing of that
event to the browser. So basically I need to communicate between
webapps in the same container.

Since Daryl seems to be satisfied with the answers he got, can I now
hijack this thread to get back to the original question, precisely ?
I am interested in the answer for a personal project.

We are thus talking about communicating between different webapps, but
within the same Tomcat container. No future scalability issue
envisioned nor desired.
I assume that the webapps run within the same instance of Tomcat,
possibly though within distinct <Host>, if it makes a difference.
I am not looking for a precise answer (which I would probably not
understand anyway), just for general guidelines about where, at which
level, it might be possible to implement some kind of inter-webapp
communication scheme.
I am thinking about the following hierarchy :
<Server>
<Service>
<Engine>
<Host>
<webapp-A />
<webapp-B />
</Host>
</Engine>
</Service>
</Server>

or this

<Server>
<Service>
<Engine>
<Host-1>
<webapp-A />
</Host-1>
<Host-2>
<webapp-B />
</Host-2>
</Engine>
</Service>
</Server>

and I want to exchange information (not just a signal) between webapp-A
and webapp-B, efficiently and reliably.
Does what I write above make sense ? is this allowed/feasible ? how hard
is it ? where ?
Could one for instance realise this in the form of a <Connector>, which
appears to live at a level common to all Hosts ?


---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Mikolaj Rydzewski]

Post by André Warnier
Does what I write above make sense ? is this allowed/feasible ? how
hard is it ? where ?
Could one for instance realise this in the form of a <Connector>,
which appears to live at a level common to all Hosts ?

You can use/modify Tomcat to allow webapps to communicate with each
other. But you shouldn't. Such solution would be bound to specific
Tomcat version only. You should rather use an existing Java
API/framework (like the ones mentioned in this thread).

[Bill Davidson]

Post by Darryl Pentz
I have an issue where webapp A needs to let webapp B know about an event, and then return a response to webapp B's processing of that event to the browser. So basically I need to communicate between webapps in the same container.
I have not found a no-brainer solution to this as yet. The one I have tried is making a localhost HTTP call which I find to be rather expensive, given that it requires creating a socket connection to the same container.

Since you're running in the same JVM, I'm not sure why you
can't set up some sort of observer-subject scheme (kind of
like ActionListener if you're familiar with that) so that the apps
can just access each other's object directly. You can set up a
singleton object to register the observers between webapps.
Just be sure to synchronize properly.

It should be pretty simple to do and dramatically more efficient
than RMI/SOAP or really anything over an IP connection. It's
hard to beat direct memory access for speed.

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Darryl Pentz]

Bill,

You would think so but it isn't that easy. Which is good to some degree, because that would seem like a scary security vulnerability. Nevertheless, besides that, Tomcats classloader hierarchy also prevents this mechanism.

It would be useful if there was some form of publish-subscribe message bus that one could, well, publish or subscribe to. I realize that JMS falls into this category, but JMS is overkill to what I'm referring to.

I recall using a message bus type of approach in a Swing application many moons ago. Forget the name of the library now. Had 'bus' in its name, perhaps somebody here knows.

Anyway, from the responses one can tell this isn't an easy peasy no brainer. *shrug*


----- Original Message ----
From: Bill Davidson <***@gmail.com>
To: Tomcat Users List <***@tomcat.apache.org>
Sent: Wednesday, October 8, 2008 8:17:56 PM
Subject: Re: Communicating between webapps

Post by Darryl Pentz
I have an issue where webapp A needs to let webapp B know about an event, and then return a response to webapp B's processing of that event to the browser. So basically I need to communicate between webapps in the same container.
I have not found a no-brainer solution to this as yet. The one I have tried is making a localhost HTTP call which I find to be rather expensive, given that it requires creating a socket connection to the same container.

Since you're running in the same JVM, I'm not sure why you
can't set up some sort of observer-subject scheme (kind of
like ActionListener if you're familiar with that) so that the apps
can just access each other's object directly. You can set up a
singleton object to register the observers between webapps.
Just be sure to synchronize properly.

It should be pretty simple to do and dramatically more efficient
than RMI/SOAP or really anything over an IP connection. It's
hard to beat direct memory access for speed.

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org




---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Caldarale, Charles R]

Post by Darryl Pentz
Subject: Re: Communicating between webapps
Nevertheless, besides that, Tomcats classloader
hierarchy also prevents this mechanism.

If you put the singleton's class in the common library, it will be accessible to both webapps. However, you have to make sure there's a bullet-proof deregistration mechanism available so that a webapp can be restarted without taking the whole container down. TANSTAAFL.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Bill Davidson]

Post by Darryl Pentz
You would think so but it isn't that easy. Which is good to some degree, because that would seem like a scary security vulnerability. Nevertheless, besides that, Tomcats classloader hierarchy also prevents this mechanism.

So if I'm understanding you correctly, different webapps use different
class loader instances and so the singleton is actually instantiated
separately
for each class loader? If that's the case then yeah, that would blow a big
hole in that idea. I didn't realize it was like that. I guess it's a
good thing
I haven't needed to do this so far.

As far as security, presumably the OP would be in control of both webapps
so that should be manageable if it was possible in the first place, which it
apparently isn't.


---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Caldarale, Charles R]

Post by Darryl Pentz
Subject: Re: Communicating between webapps
So if I'm understanding you correctly, different webapps use different
class loader instances and so the singleton is actually instantiated
separately for each class loader?

Depends on where the class file for the singleton is located. Look at this:
http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Johnny Kewl]

----- Original Message -----
From: "Darryl Pentz" <***@yahoo.com>
To: "Tomcat Users List" <***@tomcat.apache.org>
Sent: Wednesday, October 08, 2008 10:02 PM
Subject: Re: Communicating between webapps

Post by Darryl Pentz
Bill,
You would think so but it isn't that easy. Which is good to some degree,
because that would seem like a scary security vulnerability. Nevertheless,
besides that, Tomcats classloader hierarchy also prevents this mechanism.
It would be useful if there was some form of publish-subscribe message bus
that one could, well, publish or subscribe to. I realize that JMS falls
into this category, but JMS is overkill to what I'm referring to.
I recall using a message bus type of approach in a Swing application many
moons ago. Forget the name of the library now. Had 'bus' in its name,
perhaps somebody here knows.
Anyway, from the responses one can tell this isn't an easy peasy no brainer. *shrug*
----- Original Message ----
Since you're running in the same JVM, I'm not sure why you
can't set up some sort of observer-subject scheme (kind of
like ActionListener if you're familiar with that) so that the apps
can just access each other's object directly. You can set up a
singleton object to register the observers between webapps.
Just be sure to synchronize properly.

What Bill is suggesting is not that difficult... but then its probably
because we thinking outside of your framework...

Have you looked at this sort of stuff...

ServletContext ctx =
getServletContext().getContext("/someOtherContext");
RequestDispatcher rd = ctx.getNamedDispatcher("servlet-name");
rd.forward(request, response);

Cookies dont go with it... but you can play with attributes

ServletContext myContext = getServletContext();
String url = "/someWebAppPrefix";
ServletContext otherContext = myContext.getContext(url);
Object someData = otherContext.getAttribute("someKey");

This is just stuff I grabbed... not flowing code that I've tried... but in
kinda sounds like you want to forward across webapps??

Req into A... do some stuff.... set some data.... tell some servlet in
webapp B to process it and return the response... ?

... maybe...

If you really get writers block... or it starts getting really ugly...
normally means the architecture is screwed somewhere...
Do they have to be separate webapps... etc?

... good luck...

---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
If you cant pay in gold... get lost...


---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Darryl Pentz]

Johnny,

Indeed. I only yesterday discovered the crossContext flag and the getServletContext(String) call in the API, however my reading tells me that most servlet containers don't support it, being that they simply return null. For Tomcat you can specify the crossContext flag for that not to happen, but it is unique to Tomcat (I think?).

Regardless, since I am in full control of the container, and both the webapps, it is an option I'm considering. I don't like to go with 'hacks', preferring to stick to standard solutions to problems being that experience has taught me that the hacks come back to bite you in the long run, but in this case, I might make an exception.

- Darryl


----- Original Message ----
From: Johnny Kewl <***@kewlstuff.co.za>
To: Tomcat Users List <***@tomcat.apache.org>
Sent: Thursday, October 9, 2008 1:57:28 AM
Subject: Re: Communicating between webapps


----- Original Message -----
From: "Darryl Pentz" <***@yahoo.com>
To: "Tomcat Users List" <***@tomcat.apache.org>
Sent: Wednesday, October 08, 2008 10:02 PM
Subject: Re: Communicating between webapps

Post by Darryl Pentz
Bill,
You would think so but it isn't that easy. Which is good to some degree,
because that would seem like a scary security vulnerability. Nevertheless,
besides that, Tomcats classloader hierarchy also prevents this mechanism.
It would be useful if there was some form of publish-subscribe message bus
that one could, well, publish or subscribe to. I realize that JMS falls
into this category, but JMS is overkill to what I'm referring to.
I recall using a message bus type of approach in a Swing application many
moons ago. Forget the name of the library now. Had 'bus' in its name,
perhaps somebody here knows.
Anyway, from the responses one can tell this isn't an easy peasy no
brainer. *shrug*
----- Original Message ----
Since you're running in the same JVM, I'm not sure why you
can't set up some sort of observer-subject scheme (kind of
like ActionListener if you're familiar with that) so that the apps
can just access each other's object directly. You can set up a
singleton object to register the observers between webapps.
Just be sure to synchronize properly.

What Bill is suggesting is not that difficult... but then its probably
because we thinking outside of your framework...

Have you looked at this sort of stuff...

ServletContext ctx =
getServletContext().getContext("/someOtherContext");
RequestDispatcher rd = ctx.getNamedDispatcher("servlet-name");
rd.forward(request, response);

Cookies dont go with it... but you can play with attributes

ServletContext myContext = getServletContext();
String url = "/someWebAppPrefix";
ServletContext otherContext = myContext.getContext(url);
Object someData = otherContext.getAttribute("someKey");

This is just stuff I grabbed... not flowing code that I've tried... but in
kinda sounds like you want to forward across webapps??

Req into A... do some stuff.... set some data.... tell some servlet in
webapp B to process it and return the response... ?

... maybe...

If you really get writers block... or it starts getting really ugly...
normally means the architecture is screwed somewhere...
Do they have to be separate webapps... etc?

... good luck...

---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
If you cant pay in gold... get lost...


---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org




---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[André Warnier]

Hi.
This is not "my" thread, so if anyone thinks I'm pushing the envelope a
bit, tell me and I'll start another one.
I am interested in this same issue, but in a broader sense :
how to share some data, in general, between "collaborating" webapps
within the same container.

My case goes somewhat like this : an application consisting of several
webapps needs access to some common data (read/write).
Each webapp can modify this data, and the changes should be immediately
visible to the other webapps.
The data is originally loaded and parsed from a disk file, expensively.
I would like to avoid each individual webapp to have to reload and
reparse this data each time it needs to access it.
In other words, a kind of global "in-memory" DB is what I'm looking for,
where individual webapps can create/modify/read/delete "records" with
known keys, in shared mode.

I believe that this would also cover the requirements of the OP,
although it's probably more than he needs.

I realise that this can be done via e.g. an external DB.
It could also probably be done, most portably, by creating an entirely
separate application accessed via HTTP calls e.g. (à la "Amazon DB" ?).
But it looks as if "within the same container", it would be much more
efficient if kept in local memory, and avoiding overhead like TCP/IP or
JDBC or RMI.

Not being an expert in any of the underlying matters, I would just like
to know from the eperts here, but preferably without too many difficult
words like "classloader" and "dispatchers", if this is in theory
possible/allowed, if it could be done in such a way as to be portable to
a different container etc..



---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Leon Rosenberg]

Post by André Warnier
I realise that this can be done via e.g. an external DB.
It could also probably be done, most portably, by creating an entirely
separate application accessed via HTTP calls e.g. (à la "Amazon DB" ?).
But it looks as if "within the same container", it would be much more
efficient if kept in local memory, and avoiding overhead like TCP/IP or JDBC
or RMI.
Not being an expert in any of the underlying matters, I would just like to
know from the eperts here, but preferably without too many difficult words
like "classloader" and "dispatchers", if this is in theory possible/allowed,
if it could be done in such a way as to be portable to a different container
etc..

Well, it is possible by placing stuff in shared/lib and access it from
different contextes, but it will make your life extremely complicated,
especially if you start to reload applications on the fly, probably
causing an outofmemory exception at some point.
On the other side an rmi connection on the local machine is extremely
cheap (same applies to corba), if you make one call to rmi (or corba)
in one request to the application you won't even be able to measure
the transport overhead (far below 1 ms), and taking in account that
transport from browser to server is much much slower, you can ignore
the overhead. The overhead of http or soap is much higher due to
larger footprint of the call, parsing, connection issues (you have to
reconnect or handle keep alives yourself) and so on.
Behind your rmi service you can have an external db or just a hashmap
(concurrent one) or whatever serves best.
To sum it up, the TOC (total cost of ownership) of an RMI service are
much much lower as of most other solutions.

regards
Leon

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[André Warnier]

Post by Leon Rosenberg

Post by André Warnier
I realise that this can be done via e.g. an external DB.
It could also probably be done, most portably, by creating an entirely
separate application accessed via HTTP calls e.g. (à la "Amazon DB" ?).
But it looks as if "within the same container", it would be much more
efficient if kept in local memory, and avoiding overhead like TCP/IP or JDBC
or RMI.
Not being an expert in any of the underlying matters, I would just like to
know from the eperts here, but preferably without too many difficult words
like "classloader" and "dispatchers", if this is in theory possible/allowed,
if it could be done in such a way as to be portable to a different container
etc..

Well, it is possible by placing stuff in shared/lib and access it from
different contextes, but it will make your life extremely complicated,
especially if you start to reload applications on the fly, probably
causing an outofmemory exception at some point.
On the other side an rmi connection on the local machine is extremely
cheap (same applies to corba), if you make one call to rmi (or corba)
in one request to the application you won't even be able to measure
the transport overhead (far below 1 ms), and taking in account that
transport from browser to server is much much slower, you can ignore
the overhead. The overhead of http or soap is much higher due to
larger footprint of the call, parsing, connection issues (you have to
reconnect or handle keep alives yourself) and so on.
Behind your rmi service you can have an external db or just a hashmap
(concurrent one) or whatever serves best.
To sum it up, the TOC (total cost of ownership) of an RMI service are
much much lower as of most other solutions.

Many thanks.
So, assuming that I am now convinced by RMI (Remote Method Invocation
?), how would such a scheme be implemented ?
Are you talking about a separate daemon, running on the same host, which
would "offer RMI services" to all these webapps ?
Or would this "thing" be living inside Tomcat ? If so, what kind of
"thing" would this be ? It would, I guess, have to start before the
webapps do, load its original data, then remain there waiting for client
webapp RMI calls, yes ?


---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Leon Rosenberg]

Post by André Warnier

Post by Leon Rosenberg

Post by André Warnier
I realise that this can be done via e.g. an external DB.
It could also probably be done, most portably, by creating an entirely
separate application accessed via HTTP calls e.g. (à la "Amazon DB" ?).
But it looks as if "within the same container", it would be much more
efficient if kept in local memory, and avoiding overhead like TCP/IP or JDBC
or RMI.
Not being an expert in any of the underlying matters, I would just like to
know from the eperts here, but preferably without too many difficult words
like "classloader" and "dispatchers", if this is in theory
possible/allowed,
if it could be done in such a way as to be portable to a different container
etc..

Well, it is possible by placing stuff in shared/lib and access it from
different contextes, but it will make your life extremely complicated,
especially if you start to reload applications on the fly, probably
causing an outofmemory exception at some point.
On the other side an rmi connection on the local machine is extremely
cheap (same applies to corba), if you make one call to rmi (or corba)
in one request to the application you won't even be able to measure
the transport overhead (far below 1 ms), and taking in account that
transport from browser to server is much much slower, you can ignore
the overhead. The overhead of http or soap is much higher due to
larger footprint of the call, parsing, connection issues (you have to
reconnect or handle keep alives yourself) and so on.
Behind your rmi service you can have an external db or just a hashmap
(concurrent one) or whatever serves best.
To sum it up, the TOC (total cost of ownership) of an RMI service are
much much lower as of most other solutions.

Many thanks.
So, assuming that I am now convinced by RMI (Remote Method Invocation ?),
how would such a scheme be implemented ?
Are you talking about a separate daemon, running on the same host, which
would "offer RMI services" to all these webapps ?

That would be the standard way of doing it. However, it is well
possible that the RMI Service is running in one of the webapps or a
special 'dummy' webapp if you want to bundle startup/shutdown. You
would also need to start the rmiregistry which is just a programm
supplied with the jdk/jre and started by nohup rmiregistry & (on
*nix/mac)

Post by André Warnier
Or would this "thing" be living inside Tomcat ? If so, what kind of "thing"
would this be ? It would, I guess, have to start before the webapps do, load
its original data, then remain there waiting for client webapp RMI calls,
yes ?

Yes, that would be probably the best :-)

It could look like following:

public interface CentralDataService extends Remote {
void setData(String key, Object value) throws
CentralDataServiceException, RemoteException;
Object getData(String key)throws CentralDataServiceException,
RemoteException;
}

impl
public class CentralDataServiceImpl implements CentralDataService{
private Map<String,Object> data = new ConcurrentHashMap<String,Object>();

public void setData(String key, Object value){
data.put(key,value);
}

public Object getData(String key){
return data.get(key);
}

}

server, the class you start from command line if run separately.
public class CentralDataServer{

private static Logger log = Logger.getLogger(CentralDataServer.class);

private static final String REG_HOST = "localhost";
private static final int REG_PORT = Registry.REGISTRY_PORT; //default

public static void main(String a[]){
DOMConfigurator.configureAndWatch("/log4j.xml");
Registry rmiRegistry = null;
// lookup rmi registry
try{
rmiRegistry = LocateRegistry.getRegistry(REG_HOST, REG_PORT);
}catch(Exception e){
log.fatal("Coulnd't obtain rmi registry", e);
System.err.println("Coulnd't obtain rmi registry");
System.exit(-1);
}

try{
startService(rmiRegistry);
}catch(Exception e){
log.fatal("Couldn't start service", e);
System.err.println("Couldn't start service");
System.exit(-2);
}
}

public static final String getServiceId(){
//use your own well known string, might be class name
return "net_anotheria_xxx_CentralDataService";
}
public static void startService(Registry registry) throws Exception{
CentralDataService myServant = new CentralDataService();
CentralDataService rmiServant = (CentralDataService)
UnicastRemoteObject.exportObject(myServant, 0);;
// //register service.
String serviceId = getServiceId();
registry.rebind(serviceId, rmiServant);
log.info("UserServer for service " + serviceId + " is up and running.");
}
}


---------

client:

private CentralDataService myDataService;
private static Registry rmiRegistry;
static{
// lookup rmi registry
try{
rmiRegistry = LocateRegistry.getRegistry(REG_HOST, REG_PORT);
}catch(Exception e){
log.fatal("Coulnd't obtain rmi registry", e);
}
}

init(){
myDataService = rmiRegistry.lookup(CentralDataServer.getServiceId());

}

somewhere in the code:

myDataService.setData(.....)
myDataService.putData(....)...


I haven't actually compiled or tested the code but copied parts from
existing (working) code and altered it, so i don't guarantee it will
compile ;-) but it should give you the basic idea.

regards
Leon

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[André Warnier]

Leon Rosenberg wrote:
[...]
[...] (200 lines of code snipped)

Just a question : what do you answer when people ask for *really*
detailed specifications ?
:-)

Many thanks.
I'll need some time to digest that.



---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Leon Rosenberg]

Post by André Warnier
[...]
[...] (200 lines of code snipped)
Just a question : what do you answer when people ask for *really* detailed
specifications ?
:-)

Usually I'm asking them whether they are willing to pay my daily rate :-)

Leon

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Ken Bowen]

A very similar architecture would be offered by using JMS (say openjms
or activeMQ;
we've been using the latter; check for others at http://java-source.net/open-source/jms
).
In this case, there is a "message broker" which runs separately.
At the moment, we're using it on one development machine, but we fully
expect
to be using it across multiple machines, integrating both Tomcat-based
apps
as well as other non-Tomcat-based (Java) applications.

We ensure that it is started before any of the webapps start. We're
doing
this manually now, but shortly we'll be doing it by running it as a
system service.

An excellent place to start is

http://java.sun.com/products/jms/
http://java.sun.com/products/jms/tutorial/

We are only using Java clients, but one of the advantages of JMS is
that one can
utilize a wide variety of other standards-based clients.

--Ken

Post by André Warnier

Post by Leon Rosenberg

Post by André Warnier
I realise that this can be done via e.g. an external DB.
It could also probably be done, most portably, by creating an entirely
separate application accessed via HTTP calls e.g. (à la "Amazon DB" ?).
But it looks as if "within the same container", it would be much more
efficient if kept in local memory, and avoiding overhead like TCP/
IP or JDBC
or RMI.
Not being an expert in any of the underlying matters, I would just like to
know from the eperts here, but preferably without too many
difficult words
like "classloader" and "dispatchers", if this is in theory
possible/allowed,
if it could be done in such a way as to be portable to a different container
etc..

Well, it is possible by placing stuff in shared/lib and access it from
different contextes, but it will make your life extremely
complicated,
especially if you start to reload applications on the fly, probably
causing an outofmemory exception at some point.
On the other side an rmi connection on the local machine is extremely
cheap (same applies to corba), if you make one call to rmi (or corba)
in one request to the application you won't even be able to measure
the transport overhead (far below 1 ms), and taking in account that
transport from browser to server is much much slower, you can ignore
the overhead. The overhead of http or soap is much higher due to
larger footprint of the call, parsing, connection issues (you have to
reconnect or handle keep alives yourself) and so on.
Behind your rmi service you can have an external db or just a hashmap
(concurrent one) or whatever serves best.
To sum it up, the TOC (total cost of ownership) of an RMI service are
much much lower as of most other solutions.

Many thanks.
So, assuming that I am now convinced by RMI (Remote Method
Invocation ?), how would such a scheme be implemented ?
Are you talking about a separate daemon, running on the same host,
which would "offer RMI services" to all these webapps ?
Or would this "thing" be living inside Tomcat ? If so, what kind of
"thing" would this be ? It would, I guess, have to start before the
webapps do, load its original data, then remain there waiting for
client webapp RMI calls, yes ?
---------------------------------------------------------------------

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Caldarale, Charles R]

Post by Darryl Pentz
Subject: Re: Communicating between webapps
My case goes somewhat like this : an application consisting
of several webapps needs access to some common data (read/write).

What you're describing is referred to as a "bean" in Java terminology. These can range from simple ad hoc ones implemented for one specific sharing need to full-blown Enterprise Java Beans as defined in the Java EE spec. EJBs are supported by full application servers such as JBoss, but not by streamlined servlet containers like Tomcat. There are various open source packages that can be added to Tomcat to provide support for beans if you want to use them (GIYF).

The RMI mechanism espoused by Leon R is a formalized remote procedure call implementation built into the JRE. When the caller and callee are inside the same machine, the overhead is quite low but still involves object serialization and loopback TCP/IP traffic. Whether or not that's a concern depends on how much data you push across the interface. Read this for RMI info:
http://java.sun.com/javase/6/docs/platform/rmi/spec/rmiTOC.html

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Johnny Kewl]

----- Original Message -----
From: "André Warnier" <***@ice-sa.com>
To: "Tomcat Users List" <***@tomcat.apache.org>
Sent: Thursday, October 09, 2008 9:59 AM
Subject: Re: Communicating between webapps

Post by André Warnier
Hi.
This is not "my" thread, so if anyone thinks I'm pushing the envelope a
bit, tell me and I'll start another one.
how to share some data, in general, between "collaborating" webapps within
the same container.
My case goes somewhat like this : an application consisting of several
webapps needs access to some common data (read/write).
Each webapp can modify this data, and the changes should be immediately
visible to the other webapps.
The data is originally loaded and parsed from a disk file, expensively.
I would like to avoid each individual webapp to have to reload and reparse
this data each time it needs to access it.
In other words, a kind of global "in-memory" DB is what I'm looking for,
where individual webapps can create/modify/read/delete "records" with
known keys, in shared mode.
I believe that this would also cover the requirements of the OP, although
it's probably more than he needs.
I realise that this can be done via e.g. an external DB.
It could also probably be done, most portably, by creating an entirely
separate application accessed via HTTP calls e.g. (à la "Amazon DB" ?).
But it looks as if "within the same container", it would be much more
efficient if kept in local memory, and avoiding overhead like TCP/IP or
JDBC or RMI.
Not being an expert in any of the underlying matters, I would just like to
know from the eperts here, but preferably without too many difficult words
like "classloader" and "dispatchers", if this is in theory
possible/allowed, if it could be done in such a way as to be portable to a
different container etc..

There is an Application Server like this... its mine... ha ha... but is not
open soure... awe gee...
Has to be classified as "new" because we little guys... no onsite Java
campus here ;)

We use it to do exactly this kind of thing... I'm proud of it, and it has
become our core internal tool of choice... but only use it in experimental
stuff.

Its a webapp... so you drop it into any Tomcat...
Its not "bean" based, it runs applications...

In your case this is what we would do...

Make the Java Lib... test it in your webapp as normal...

When you ready drop it nto the Harbor webapp...
Then in any Tomcat that wants to use it...

vessel = new Vessel("URL OF HARBOR TOMCAT");
i_MailEngine =
(I_MailEngine)vessel.loadRemoteSingleton(I_MailEngine.class,"kewlstuff.harbor.mailer.MailEngine","APP_ID");


... use that class.... eg

i_MailEngine.Send("message"); // etc

Like RMI and all the rest its doing serialization and typically one has to
know how to use an interface with a class... but thats it.

If we did this....

Class uiApp = vessel.getRemoteClass("kewlstuff.mailer.test.ui.UI");

Then that class runs on the users machine... so even our Swing apps now live
in Tomcat...

Its like RMI but my baby runs full applications.... for example in one app
we have, we load up a client side, that actually uses a complete H2 dB... on
the client (not installed on the client) and we leave the Postgres side on
the server... all still works as one app ;)

Andre all these tools are on the EJB spectrum... thats where you actually
going...
RMI is remote procedure calls
EJB is RMI with Beans
PAS (my baby) is remote applications.

The PAS is http based thus no Registry stuff needed... it addresses in the
same way the internet does... so there are differences, but underneath its
all much of the same core technologies... sockets are talking, data is
serializing, classes are moving over the wire... yada yada

RMI and My Baby are binary based... and that why they kick a web services
butt (SOAP is wrapped in XML) its got to translate images to text and and
and...
But Soap will work between .Net and Java... in theory anyway... the PAS is
Java only...

These tools work across the world... doesnt have to be in the same TC... if
it is, then all this stuff reduces to a little old Class (or the lesser
bean) in little old Java.

You have to study the stuff out there... and you need to try them... I
remember rushing out years ago, and getting all excited about SOAP (web
services)... damn that is slow... the answer is always... it depends...

I'm very much for the KISS principle... if you dont need it, dont use it...
nothing is more powerful that POJO (plain old Java).
Thing is KISS does not mean novice... you'll find only the guys that have
been around for a while can really KISS ;)

Have fun... study em all...

---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
If you cant pay in gold... get lost...


---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Leon Rosenberg]

Post by Johnny Kewl
I'm very much for the KISS principle... if you dont need it, dont use it...
nothing is more powerful that POJO (plain old Java).
Thing is KISS does not mean novice... you'll find only the guys that have
been around for a while can really KISS ;)

just a side note Johnny,
you need a container for something that can be done without, how is that KIS(S)?

regards
Leon

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Johnny Kewl]

----- Original Message -----
From: "Leon Rosenberg" <***@googlemail.com>
To: "Tomcat Users List" <***@tomcat.apache.org>
Sent: Thursday, October 09, 2008 9:54 PM
Subject: Re: Communicating between webapps

Post by Leon Rosenberg

Post by Johnny Kewl
I'm very much for the KISS principle... if you dont need it, dont use it...
nothing is more powerful that POJO (plain old Java).
Thing is KISS does not mean novice... you'll find only the guys that have
been around for a while can really KISS ;)

just a side note Johnny,
you need a container for something that can be done without, how is that KIS(S)?

I'm just saying that I think a lot of time people lock themselves into
complex technology, additional containers, whatever, and if they had just
thought about it, done it slightly differently, they would have done it all
in a little old webapp...
Not into driving a CV and sending poor admin people to the funny farm...
kind of thing.
Simple as possible is best... if you dont have to use an additional
container, dont, whether that be mine or yours... I think

---------------------------------------------------------------------------
HARBOR : http://www.kewlstuff.co.za/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm
---------------------------------------------------------------------------
If you cant pay in gold... get lost...


---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[André Warnier]

Thanks to all for the answers, and an interesting thread.
As just an occasional dabbler into this, I must say that the more I dig
into Java, the more I get the impression that this is a language that
needs lifetime dedication in order to fully understand the beauties of
it. I am starting to understand why the designers built introspection
into it, so it could look into itself. I think that was revenge.


---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Darryl Pentz]

It's my thread, but you're welcome to it now. I'm done. :-)


----- Original Message ----
From: André Warnier <***@ice-sa.com>
To: Tomcat Users List <***@tomcat.apache.org>
Sent: Thursday, October 9, 2008 9:59:50 AM
Subject: Re: Communicating between webapps

Hi.
This is not "my" thread, so if anyone thinks I'm pushing the envelope a
bit, tell me and I'll start another one.
I am interested in this same issue, but in a broader sense :
how to share some data, in general, between "collaborating" webapps
within the same container.

My case goes somewhat like this : an application consisting of several
webapps needs access to some common data (read/write).
Each webapp can modify this data, and the changes should be immediately
visible to the other webapps.
The data is originally loaded and parsed from a disk file, expensively.
I would like to avoid each individual webapp to have to reload and
reparse this data each time it needs to access it.
In other words, a kind of global "in-memory" DB is what I'm looking for,
where individual webapps can create/modify/read/delete "records" with
known keys, in shared mode.

I believe that this would also cover the requirements of the OP,
although it's probably more than he needs.

I realise that this can be done via e.g. an external DB.
It could also probably be done, most portably, by creating an entirely
separate application accessed via HTTP calls e.g. (à la "Amazon DB" ?).
But it looks as if "within the same container", it would be much more
efficient if kept in local memory, and avoiding overhead like TCP/IP or
JDBC or RMI.

Not being an expert in any of the underlying matters, I would just like
to know from the eperts here, but preferably without too many difficult
words like "classloader" and "dispatchers", if this is in theory
possible/allowed, if it could be done in such a way as to be portable to
a different container etc..



---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org




---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Christopher Schultz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Darryl,

Post by Darryl Pentz
I also just encountered the 'crosscontext' attribute in the
<context.../> block and was wondering whether that could serve any
purpose.

If you don't mind issuing another request (not a new HTTP connection,
just another request dispatched within Tomcat), you can use "cross
context" like this. The docs for that option say:

"Set to true if you want calls within this application to
ServletContext.getContext() to successfully return a request dispatcher
for other web applications running on this virtual host. Set to false
(the default) in security conscious environments, to make getContext()
always return null."

That means that if you have webappA deployed to /webappA and webappB
deployed to /webappB in the same container, then you should be able to
do this in a servlet in webappA:

ServletContext application = getServletContext();
ServletContext webappB = application.getContext("/webappB/service/to/call");
RequestDispatcher dispatcher =
webappB.getRequestDispatcher("/service/to/call");

// Invoke webapp B's service
dispatcher.forward(request, response);

- -----

Now, if this works, you have some options. Obviously, you don't simply
want to turn processing completely over to webappB's service. In that
case, you should be able to create your own HttpServletRequest and
HttpServletResponse objects (or wrap the existing ones already available
from the current invocation) and use /those/ with the dispatcher. Than,
you can pick and choose what happens to the response.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjvsfAACgkQ9CaO5/Lv0PD4zgCgvMqDxgAl+AkI7Do6LeHTSTct
O/8An0po+B4IBbHgSeNZppucLa/IUP8R
=EcZu
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: ***@tomcat.apache.org
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org