Re: [OT] Communicating between webapps
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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darryl, Darryl Pentz wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darryl, Darryl Pentz wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
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 [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, October 9, 2008 1:57:28 AM Subject: Re: Communicating between webapps - Original Message - From: Darryl Pentz [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, October 08, 2008 10:02 PM Subject: Re: Communicating between webapps 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 [EMAIL PROTECTED] 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
It's my thread, but you're welcome to it now. I'm done. :-) - Original Message From: André Warnier [EMAIL PROTECTED] To: Tomcat Users List users@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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
On Thu, Oct 9, 2008 at 9:59 AM, André Warnier [EMAIL PROTECTED] wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
On Thu, Oct 9, 2008 at 10:36 AM, André Warnier [EMAIL PROTECTED] wrote:
Leon Rosenberg wrote:
On Thu, Oct 9, 2008 at 9:59 AM, André Warnier [EMAIL PROTECTED] wrote:
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)
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 MapString,Object data = new ConcurrentHashMapString,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.
Re: Communicating between webapps
Leon Rosenberg wrote: [...] It could look like following: [...] (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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
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 On Oct 9, 2008, at 4:36 AM, André Warnier wrote: Leon Rosenberg wrote: On Thu, Oct 9, 2008 at 9:59 AM, André Warnier [EMAIL PROTECTED] wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
On Thu, Oct 9, 2008 at 1:01 PM, André Warnier [EMAIL PROTECTED] wrote: Leon Rosenberg wrote: [...] It could look like following: [...] (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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Leon Rosenberg wrote: On Thu, Oct 9, 2008 at 9:59 AM, André Warnier [EMAIL PROTECTED] wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Communicating between webapps
From: André Warnier [mailto:[EMAIL PROTECTED] 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Communicating between webapps
From: Bill Davidson [mailto:[EMAIL PROTECTED] 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
- Original Message - From: André Warnier [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, October 09, 2008 9:59 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.. 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
Re: Communicating between webapps
On Thu, Oct 9, 2008 at 7:16 PM, Johnny Kewl [EMAIL PROTECTED] wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
- Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, October 09, 2008 9:54 PM Subject: Re: Communicating between webapps On Thu, Oct 9, 2008 at 7:16 PM, Johnny Kewl [EMAIL PROTECTED] wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
RMI, CORBA or (worst choice) SOAP. Everything else, like using libs in shared/server folders etc are hacks :-) Leon On Wed, Oct 8, 2008 at 10:53 AM, Darryl Pentz [EMAIL PROTECTED] wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Leon Rosenberg wrote: RMI, CORBA or (worst choice) SOAP. Everything else, like using libs in shared/server folders etc are hacks :-) Leon On Wed, Oct 8, 2008 at 10:53 AM, Darryl Pentz [EMAIL PROTECTED] wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Communicating between webapps
From: André Warnier [mailto:[EMAIL PROTECTED] 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. 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. 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
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 [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, October 8, 2008 12:54:10 PM Subject: Re: Communicating between webapps Leon Rosenberg wrote: 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 [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Leon Rosenberg wrote: 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 [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Brantley Hobbs wrote: Darryl Pentz wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
On Wed, Oct 8, 2008 at 12:00 PM, Mikolaj Rydzewski [EMAIL PROTECTED] wrote: Darryl Pentz wrote: 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 -- Mikolaj Rydzewski [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Darryl Pentz wrote: 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. -- Mikolaj Rydzewski [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Darryl Pentz wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Darryl Pentz wrote: 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. -- Mikolaj Rydzewski [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Mikolaj Rydzewski wrote: Leon Rosenberg wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Communicating between webapps
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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Darryl Pentz wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
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 [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, October 8, 2008 8:17:56 PM Subject: Re: Communicating between webapps Darryl Pentz wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Communicating between webapps
From: Darryl Pentz [mailto:[EMAIL PROTECTED] 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
Darryl Pentz wrote: 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Communicating between webapps
- Original Message - From: Darryl Pentz [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, October 08, 2008 10:02 PM Subject: Re: Communicating between webapps 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 [EMAIL PROTECTED] 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: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
