You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Shapira, Yoav" <Yo...@mpi.com> on 2002/09/04 21:43:37 UTC
RE: [Q] Singleton Objects across webapps...
Hi,
Perhaps putting the common code, e.g. the singleton, in /common/lib will
work for you?
Yoav Shapira
Millennium ChemInformatics
>-----Original Message-----
>From: Per Kreipke [mailto:per@onclave.com]
>Sent: Wednesday, September 04, 2002 3:44 PM
>To: Tomcat Users List
>Subject: RE: [Q] Singleton Objects across webapps...
>
>I hate to repost but I'm not clear why no one has any advice.
>
>Am I asking such a simple question that I just missed it in the FAQ
>somewhere?
>
>_any_ pointer is appreciated.
>
>Per
>
>> A "best practices" question:
>>
>> What is the best way of sharing a single, changeable copy of common
>> information across multiple servlets?
>>
>>
>> Example Scenario:
>>
>> Using two servlets (webdav and cocoon), I need to share common
>information
>> between them.
>>
>> There are two choices for how to host the servlets, each of which
affects
>> the options for sharing info:
>>
>> - host the servlets in different contexts (a likely requirement
>> if security
>> constraints differ)
>>
>> - host the servlets in the same context.
>>
>>
>> Then, within each servlet you could share the information through:
>> - singleton classes
>> + pro: conceptually simple
>> + con: singleton pattern isn't bulletproof
>> + con: threading issues?
>> + con: lifecyle issues (can't use servlet destroy() if have multiple
>> servlets)
>>
>> - avalon roles
>> + pro: convenient, correct lifecycle management
>> + pro: using avalon in other apps (James) in same JVM could also
>> share info
>> + con: poolable (e.g. multiple instances) and not the same as
singleton
>>
>> - context attributes
>> + pro: conceptually simple, no singleton coding necessary
>> + con: HTTP specific, information can't be shared with non TC app
>(James)
>> + con: can't share across contexts, all servlets must live in same
>webapp
>>
>> - enterprise javabeans
>> + pro: managed
>> + con: requires J2EE server?
>>
>> 1) Are there other options I'm missing?
>>
>> 2) What have people found to be the best pattern?
>>
>> 3) Besides the servlet 2.3 reference docs and O'Reilly books, can
anyone
>> recommend reading material that includes these issues (most
introductory
>> books cover the same 'your first webapp' type of material).
>>
>>
>> Thanks in advance for your opinion,
>> Per
>
>
>--
>To unsubscribe, e-mail: <mailto:tomcat-user-
>unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:tomcat-user-
>help@jakarta.apache.org>
Re: [Q] Singleton Objects across webapps...
Posted by Eddie Bush <ek...@swbell.net>.
I don't think web services require EJBs be used :-) I haven't fooled
around with them though. From what I recall having read, you can do web
services using Tomcat. What I read, and where, I do not recall
precisely. The "impression I have left upon my mind" is that it is
possible to do web services under TC. Search, read, and educate
yourself about web services. One particular point of interest: Sun has
the web services developer pack, and I believe Apache (Jakarta) has a
similar project. ... now, if only I could remember where I got that
from so I could come up with the name.
If you feel you must use EJBs, JBoss is most likely the direction you
want to go. If you can do what you want without EJBs, you don't need
JBoss. That is my understanding -- I am far from authoritative on
anything having to do with EJBs.
Regards,
Eddie
Felipe Schnack wrote:
> So, if I need webservices and such I should use JBoss?
>
>On Thu, 2002-09-05 at 12:03, Eddie Bush wrote:
>
>>Felipe Schnack wrote:
>>
>>> That was something I was asking myself some days ago: why i would use
>>>JBoss?
>>>
>>That I'm aware of, TC doesn't "do" EJBs. TC is a servlet container.
>> JBoss is a full J2EE application server (someone help me out here --
>>the lines are fuzzy to me too) -- in other words, it'll handle all the
>>EJB-type stuff that TC doesn't get involved in. I believe it delegates
>>all Servlet/JSP/whatever (ie non-EJB-type stuff) to TC.
>>
>>Regards,
>>
>>Eddie
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Q] Singleton Objects across webapps...
Posted by Felipe Schnack <fe...@ritterdosreis.br>.
So, if I need webservices and such I should use JBoss?
On Thu, 2002-09-05 at 12:03, Eddie Bush wrote:
> Felipe Schnack wrote:
>
> > That was something I was asking myself some days ago: why i would use
> >JBoss?
> >
> That I'm aware of, TC doesn't "do" EJBs. TC is a servlet container.
> JBoss is a full J2EE application server (someone help me out here --
> the lines are fuzzy to me too) -- in other words, it'll handle all the
> EJB-type stuff that TC doesn't get involved in. I believe it delegates
> all Servlet/JSP/whatever (ie non-EJB-type stuff) to TC.
>
> Regards,
>
> Eddie
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893
Faculdade Ritter dos Reis
www.ritterdosreis.br
felipes@ritterdosreis.br
Fone/Fax.: (51)32303328
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: manually set cookie path for JSESSIONID
Posted by Milt Epstein <me...@uiuc.edu>.
On 6 Sep 2002, Benny Lootens wrote:
> Hi Milt,
>
> I understand it now, and I'm just gonna make different contexts for
> different hostnames, eg www.domaina.com would refer to context
> /domaina and www.domainb.com would refer to context /domainb.
OK, that should work (although I don't really know what you're trying
to do :-). But you can probably get by with using the same context as
well. Remember, cookies have a domain as well as a path, and the
browser uses both those pieces of information when deciding whether to
send a cookie with a particular URL. So, since you have different
domains, that should keep the cookies separate.
Milt Epstein
Research Programmer
Systems and Technology Services (STS)
Campus Information Technologies and Educational Services (CITES)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: manually set cookie path for JSESSIONID
Posted by Benny Lootens <be...@verzekeringen.be>.
Hi Milt,
I understand it now, and I'm just gonna make different contexts for
different hostnames, eg www.domaina.com would refer to context /domaina
and www.domainb.com would refer to context /domainb.
Thank you for the quick answer !
greetings,
benny lootens
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: manually set cookie path for JSESSIONID
Posted by Milt Epstein <me...@uiuc.edu>.
On 5 Sep 2002, Benny Lootens wrote:
> Hi,
>
> I really have a problem here ... :-(
>
> Two different URLS, www.mydomain-a.com and www.mydomain-b.com point
> to the same webapplication, the same tomcat-context.
>
> Everything works fine, even if I start working with cookies (I set a
> different cookiepath for each URL, eg. /cookiepatha for
> mydomain-a.com and /cookiepathb for mydomain-b.com), but I have
What do you mean by this, that is, how/where do you set the
cookiepath?
> still 1 problem:
>
> tomcat 3.2.4 always set the cookie path of the JSESSIONID to the
> name of the web application context patch! So, this would be:
Yes, that is how it works, session cookies are context specific (and
that's captured in the path setting).
> /cookiepatha for mydomain-a.com and
> /cookiepatha for mydomain-b.com, but this one should be /cookiepathb
> iso /cookiepatha. Can i set the latter manually for the
> cookievariable JSESSIONID?
[ ... ]
Don't think so -- at least, not without mucking with the Tomcat
source, and I think if you did that to get the above you'd be going
against the spec.
There are a couple of things I don't understand, however. First, why
do you have the two domains pointing to the same webapplication.
Second, why do you need the different cookiepath's?
Maybe if you elaborate on why you're doing these things, and/or what
you're trying to do overall, we can figure out a solution.
Milt Epstein
Research Programmer
Systems and Technology Services (STS)
Campus Information Technologies and Educational Services (CITES)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
manually set cookie path for JSESSIONID
Posted by Benny Lootens <be...@verzekeringen.be>.
Hi,
I really have a problem here ... :-(
Two different URLS, www.mydomain-a.com and www.mydomain-b.com point to
the same webapplication, the same tomcat-context.
Everything works fine, even if I start working with cookies (I set a
different cookiepath for each URL, eg. /cookiepatha for mydomain-a.com
and /cookiepathb for mydomain-b.com), but I have still 1 problem:
tomcat 3.2.4 always set the cookie path of the JSESSIONID to the name of
the web application context patch! So, this would be:
/cookiepatha for mydomain-a.com and
/cookiepatha for mydomain-b.com, but this one should be /cookiepathb iso
/cookiepatha. Can i set the latter manually for the cookievariable
JSESSIONID?
Any help would really be appreciated.
regards,
benny lootens
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Q] Singleton Objects across webapps...
Posted by Eddie Bush <ek...@swbell.net>.
Felipe Schnack wrote:
> That was something I was asking myself some days ago: why i would use
>JBoss?
>
That I'm aware of, TC doesn't "do" EJBs. TC is a servlet container.
JBoss is a full J2EE application server (someone help me out here --
the lines are fuzzy to me too) -- in other words, it'll handle all the
EJB-type stuff that TC doesn't get involved in. I believe it delegates
all Servlet/JSP/whatever (ie non-EJB-type stuff) to TC.
Regards,
Eddie
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Q] Singleton Objects across webapps...
Posted by Felipe Schnack <fe...@ritterdosreis.br>.
That was something I was asking myself some days ago: why i would use
JBoss?
On Wed, 2002-09-04 at 20:06, Eddie Bush wrote:
> Comments in-line.
>
> Shapira, Yoav wrote:
>
> >Hi,
> >Perhaps putting the common code, e.g. the singleton, in /common/lib will
> >work for you?
> >
> >Yoav Shapira
> >Millennium ChemInformatics
> >
> >>>A "best practices" question:
> >>>
> >>>What is the best way of sharing a single, changeable copy of common
> >>>information across multiple servlets?
> >>>
> >>>
> >>>Example Scenario:
> >>>
> >>>Using two servlets (webdav and cocoon), I need to share common
> >>>
> >>information
> >>
> >>>between them.
> >>>
> >>>There are two choices for how to host the servlets, each of which
> >>>
> >affects
> >
> >>>the options for sharing info:
> >>>
> >>>- host the servlets in different contexts (a likely requirement
> >>>if security
> >>>constraints differ)
> >>>
> >>>- host the servlets in the same context.
> >>>
> >>>
> >>>Then, within each servlet you could share the information through:
> >>>- singleton classes
> >>> + pro: conceptually simple
> >>> + con: singleton pattern isn't bulletproof
> >>> + con: threading issues?
> >>> + con: lifecyle issues (can't use servlet destroy() if have multiple
> >>>servlets)
> >>>
> What threading issues would you have that synchronization wouldn't cure?
> It depends on the nature of your data/how volatile it is. If it's
> especially volatile, the singleton could (conceivably - you'd have to
> test to see) become a bottleneck. If most of your access is read-only,
> I don't see how this is an issue. You have to sit down and take a look
> at who (and how many whos) can modify the data. How many would (really)
> do it simultaneously? I'd highly recommend synchronizing your mutators
> in either case. The fewer people that have the ability to update, the
> less likely this will ever become a bottleneck.
>
> >>>- avalon roles
> >>> + pro: convenient, correct lifecycle management
> >>> + pro: using avalon in other apps (James) in same JVM could also
> >>>share info
> >>> + con: poolable (e.g. multiple instances) and not the same as
> >>>
> >singleton
> >
> Not familiar with them.
>
> >>>- context attributes
> >>> + pro: conceptually simple, no singleton coding necessary
> >>> + con: HTTP specific, information can't be shared with non TC app
> >>>
> >>(James)
> >>
> >>> + con: can't share across contexts, all servlets must live in same
> >>>
> >>webapp
> >>
> *nod* ... and?
>
> >>>- enterprise javabeans
> >>> + pro: managed
> >>> + con: requires J2EE server?
> >>>
> Ok, so use JBoss instead of TC (I think JBoss actually includes TC).
> I'm not very familiar with this either.
>
> >>>1) Are there other options I'm missing?
> >>>
> How about keeping the data in a database and devising a cache mechanism
> that will refresh the cash at a user-defined interval? You've just
> solved your concurrent updates problem, assuming you use a DMBS that
> thinks ACID is good (ie MySQL would not be my first choice ---
> PostgreSQL is a good open-source solution).
>
> >>>2) What have people found to be the best pattern?
> >>>
> I think that would depend entirely on your given application :-) My
> general rule of thumb is to introduce no more complexity than I
> absolutely have to in order to acheive the required functionality. For
> a small application, the singleton would (most likely) be fine. For a
> large one, EJBs maybe (I'm totally unfamiliar with them, so I can't say
> with any authority). I would probably, on a large-scale project
> requiring a lot of simultaneous updates of cached data, use a database.
>
> >>>3) Besides the servlet 2.3 reference docs and O'Reilly books, can
> >>>
> >anyone
> >
> >>>recommend reading material that includes these issues (most
> >>>
> >introductory
> >
> >>>books cover the same 'your first webapp' type of material).
> >>>
> Not off-hand -- nope. Sorry :-(
>
> >>>Thanks in advance for your opinion,
> >>>Per
> >>>
> No problem -- that'll be $9.95, please. Would you like fries with that?
> Just kidding ... :-) Maybe, if nothing else, I'll bump your post up
> and someone more authoritative will pipe up.
>
> Regards,
>
> Eddie
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893
Faculdade Ritter dos Reis
www.ritterdosreis.br
felipes@ritterdosreis.br
Fone/Fax.: (51)32303328
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Q] Singleton Objects across webapps...
Posted by Eddie Bush <ek...@swbell.net>.
Comments in-line.
Shapira, Yoav wrote:
>Hi,
>Perhaps putting the common code, e.g. the singleton, in /common/lib will
>work for you?
>
>Yoav Shapira
>Millennium ChemInformatics
>
>>>A "best practices" question:
>>>
>>>What is the best way of sharing a single, changeable copy of common
>>>information across multiple servlets?
>>>
>>>
>>>Example Scenario:
>>>
>>>Using two servlets (webdav and cocoon), I need to share common
>>>
>>information
>>
>>>between them.
>>>
>>>There are two choices for how to host the servlets, each of which
>>>
>affects
>
>>>the options for sharing info:
>>>
>>>- host the servlets in different contexts (a likely requirement
>>>if security
>>>constraints differ)
>>>
>>>- host the servlets in the same context.
>>>
>>>
>>>Then, within each servlet you could share the information through:
>>>- singleton classes
>>> + pro: conceptually simple
>>> + con: singleton pattern isn't bulletproof
>>> + con: threading issues?
>>> + con: lifecyle issues (can't use servlet destroy() if have multiple
>>>servlets)
>>>
What threading issues would you have that synchronization wouldn't cure?
It depends on the nature of your data/how volatile it is. If it's
especially volatile, the singleton could (conceivably - you'd have to
test to see) become a bottleneck. If most of your access is read-only,
I don't see how this is an issue. You have to sit down and take a look
at who (and how many whos) can modify the data. How many would (really)
do it simultaneously? I'd highly recommend synchronizing your mutators
in either case. The fewer people that have the ability to update, the
less likely this will ever become a bottleneck.
>>>- avalon roles
>>> + pro: convenient, correct lifecycle management
>>> + pro: using avalon in other apps (James) in same JVM could also
>>>share info
>>> + con: poolable (e.g. multiple instances) and not the same as
>>>
>singleton
>
Not familiar with them.
>>>- context attributes
>>> + pro: conceptually simple, no singleton coding necessary
>>> + con: HTTP specific, information can't be shared with non TC app
>>>
>>(James)
>>
>>> + con: can't share across contexts, all servlets must live in same
>>>
>>webapp
>>
*nod* ... and?
>>>- enterprise javabeans
>>> + pro: managed
>>> + con: requires J2EE server?
>>>
Ok, so use JBoss instead of TC (I think JBoss actually includes TC).
I'm not very familiar with this either.
>>>1) Are there other options I'm missing?
>>>
How about keeping the data in a database and devising a cache mechanism
that will refresh the cash at a user-defined interval? You've just
solved your concurrent updates problem, assuming you use a DMBS that
thinks ACID is good (ie MySQL would not be my first choice ---
PostgreSQL is a good open-source solution).
>>>2) What have people found to be the best pattern?
>>>
I think that would depend entirely on your given application :-) My
general rule of thumb is to introduce no more complexity than I
absolutely have to in order to acheive the required functionality. For
a small application, the singleton would (most likely) be fine. For a
large one, EJBs maybe (I'm totally unfamiliar with them, so I can't say
with any authority). I would probably, on a large-scale project
requiring a lot of simultaneous updates of cached data, use a database.
>>>3) Besides the servlet 2.3 reference docs and O'Reilly books, can
>>>
>anyone
>
>>>recommend reading material that includes these issues (most
>>>
>introductory
>
>>>books cover the same 'your first webapp' type of material).
>>>
Not off-hand -- nope. Sorry :-(
>>>Thanks in advance for your opinion,
>>>Per
>>>
No problem -- that'll be $9.95, please. Would you like fries with that?
Just kidding ... :-) Maybe, if nothing else, I'll bump your post up
and someone more authoritative will pipe up.
Regards,
Eddie
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>