Large finders on entity beans refactored

Google

Mailing List

Home

Forum Home

JBoss - Java Application Server

Struts - A MVC web framework

Tomcat - JSP/Servlet container

iText - An open source PDF Java Library

JDOM - JDOM XML Parser

J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition

J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog

Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology

JSP - A mailing list about Java Server Pages specification and reference

Struts & Hibernate

Subjects

•	JSP editor plugin for eclipse ?
•	org apache jasper JasperException: Unable to compile class for JSP
•	Tomcat: Connection reset by peer: socket write error
•	Cannot retrieve definition for form bean null
•	Struts Tiles Tutorial (free Struts training)
•	Where do I download Tomcat 4 0 6?
•	Data Access Object (DAO) pattern, example DAO 's
•	Where to download Tomcat v 4 1 24 from?
•	Tomcat 5 0 16 Requested resource not available
•	Oracle Connection Pooling in 3 2 2
•	Servlet : Session invalidate
•	Servlet action is currently unavailable
•	Tomcat/Struts Unicode Encoding/Decoding problems
•	Tomcat and webapplication specific java library path
•	Running a Simple JMS Example
•	Mapping in workers2 properties
•	org apache jasper JasperException
•	Cannot find message resources under key org apache struts action MESSAGE
•	problem with html:text bean throwing exception
•	Cannot find message resources under key org apache struts action MESSAGE
•	invalid direct reference problem with solution
•	Tool for jsp debug Try Sysdeo Eclipse Plugin
•	Tomcat 5 Cannot load JDBC driver class 'null ' SQL state: null
•	weblogic ejbc
•	java properties file
•	Jboss 3 2 3 Coyote Can 't re
•	Tomcat 5, Apache2 and mod jk2 integration problem
•	JBoss example problem new to J2EE
•	url string for connecting jboss to oracle
•	Value attribute of <html:checkbox
•	javax servlet ServletException: BeanUtils populate
•	HTTP Status 404 The requested resource is not available
•	5 0 18: Windows XP Pro vs Windows 2000

Large finders on entity beans refactored

Large finders on entity beans refactored

2003-09-19 - By Pradeep Kumar

Back

Reply: 1 2 3 4 5 6 7 8 9 10 >>

To me the specs statement contradicts the behavior of the finder methods. The
very purpose of finding is to first get all the identities (primary keys), so
now that you have the identities, how could the container not keep them in
the ready state and loose the object identities (pooled state do not have any
identities).

I don?t get it when you say that the identity is not given to the objects
until the client has requested. Where and how else the identities are
maintained by the container?

-- --Original Message-- --
From: Kalra, Ashwani [mailto:ashwani.kalra@(protected)]
Sent: Friday, September 19, 2003 9:54 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Large finders on entity beans refactored

Here is what specs says
"After the ejbFind<METHOD>(...) method completes, the instance remains in the
pooled
state. The container may, but is not required to, immediately activate the
objects that were
located by the finder using the transition through the ejbActivate() method.
" Section 10.5.3 page no 177 of EJB 2.0

It doesnt give identity till there is request by client. But there is cost of
construction of Remote interfaces that it return to the client for multi
object finders.
HTH
/Ashwani

-- --Original Message-- --
From: Pradeep Kumar [mailto:pradeepk@(protected)]
Sent: Friday, September 19, 2003 9:30 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Large finders on entity beans refactored
While the container is executing the finder method, it must give identities
to each of the objects (primary keys). Hence, they must be placed in the
ready state, since objects do not have any identity in the pooled state.

Can someone please clarify the statement from the specs.

-- --Original Message-- --
From: Kalra, Ashwani [mailto:ashwani.kalra@(protected)]
Sent: Thursday, September 18, 2003 7:28 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Large finders on entity beans refactored

Here what I read from specs 2.0

"The instance does not move to the ready state during the execution of a
finder or a home
method."
-- --Original Message-- --
From: Pradeep Kumar [mailto:pradeepk@(protected)]
Sent: Monday, September 15, 2003 9:54 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Large finders on entity beans refactored
I totally agree. We are told that if we read a large amt of data via entity
beans, there will be too many entity objects in ready state. One can argue,
that they will be the cached data for subsequent reads (lets? say via find by
primary key), however, to avoid dirty reads, the container calls the EJB load
method, which defeats the purpose of caching

-- --Original Message-- --
From: Katz Guy [mailto:Guy_Katz@(protected)]
Sent: Sunday, September 14, 2003 12:12 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Large finders on entity beans refactored

Hi;
Going through the core patterns book.
There is a bad practice dedicated to not using finder methods when large
result is expected but use a DAO instead.
My understanding is that the authors want to have a 'dual interface' for
access to the same data, Modeling the data itself as entity beans yet using
DAO for the search. Is this correct?
If so, wouldn't this be in contrast to resusability? Also, isnt this a good
place to put your money on vendor container optimiations?
__ ____ ____ ____ _____
Guy Katz
Software Architect, CAP-IFS
Comverse
guy.katz@(protected)
+972 3 7663686
DISCLAIMER:
This message (including attachment if any) is confidential and may be
privileged. Before opening attachments please check them for viruses and
defects. MindTree Consulting Private Limited (MindTree) will not be
responsible for any viruses or defects or any forwarded attachments emanating
either from within MindTree or outside. If you have received this message by
mistake please notify the sender by return e-mail and delete this message
from your system. Any unauthorized use or dissemination of this message in
whole or in part is strictly prohibited. Please note that e-mails are
susceptible to change and MindTree shall not be liable for any improper,
untimely or incomplete transmission.
====================================================================
Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatterns List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatterns List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
DISCLAIMER:
This message (including attachment if any) is confidential and may be
privileged. Before opening attachments please check them for viruses and
defects. MindTree Consulting Private Limited (MindTree) will not be
responsible for any viruses or defects or any forwarded attachments emanating
either from within MindTree or outside. If you have received this message by
mistake please notify the sender by return e-mail and delete this message
from your system. Any unauthorized use or dissemination of this message in
whole or in part is strictly prohibited. Please note that e-mails are
susceptible to change and MindTree shall not be liable for any improper,
untimely or incomplete transmission.
__ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____
This message contains information that may be privileged or confidential and
is the property of the Cap Gemini Ernst & Young Group. It is intended only
for the person to whom it is addressed. If you are not the intended
recipient, you are not authorised to read, print, retain, copy, disseminate,
distribute, or use this message or any part thereof. If you receive this
message in error, please notify the sender immediately and delete all copies
of this message.
====================================================================
Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatterns List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatterns List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)

__ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____
This message contains information that may be privileged or confidential and
is the property of the Cap Gemini Ernst & Young Group. It is intended only
for the person to whom it is addressed. If you are not the intended
recipient, you are not authorised to read, print, retain, copy, disseminate,
distribute, or use this message or any part thereof. If you receive this
message in error, please notify the sender immediately and delete all copies
of this message.
====================================================================
Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatterns List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)

DISCLAIMER:
This message (including attachment if any) is confidential and may be
privileged. Before opening attachments please check them for viruses and
defects. MindTree Consulting Private Limited (MindTree) will not be responsible
for any viruses or defects or any forwarded attachments emanating either from
within MindTree or outside. If you have received this message by mistake please
notify the sender by return e-mail and delete this message from your system.
Any unauthorized use or dissemination of this message in whole or in part is
strictly prohibited. Please note that e-mails are susceptible to change and
MindTree shall not be liable for any improper, untimely or incomplete
transmission.

====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas
-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255 (See http://ows-1255.ora-code.com)">

<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 9">
<meta name=Originator content="Microsoft Word 9">
<link rel=File-List href="cid:filelist.xml@(protected)">
<title>Large finders on entity beans refactored</title>

<style>

</style>
</head>

<body lang=EN-US style='tab-interval:.5in'>

<div class=Section1>

To me the specs statement contradicts the behavior of the finder
methods. The very purpose of finding is to first get all the identities (primary
keys), so now that you have the identities, how could the container not keep
them in the ready state and loose the object identities (pooled state do not
have any identities). <o:p></o:p>

<![if !supportEmptyParas]> <![endif]><o:p></o:p>

I don?t get it when you say that the identity is not given to the
objects until the client has requested. Where and how else the identities are
maintained by the container?<o:p></o:p>

<![if !supportEmptyParas]> <![endif]><o:p></o:p>

----
-Original
Message-- -- 
From: Kalra, Ashwani
[mailto:ashwani.kalra@(protected)] 
Sent: Friday, September 19, 2003
9:54 AM 
To:
J2EEPATTERNS-INTEREST@(protected) 
Subject: Re: Large finders on
entity beans refactored

<![if !supportEmptyParas]> <![endif]><o:p></o:p>

Here is what specs says<o:p></o:p>


"After the ejbFind<METHOD>(...) 
method completes, the instance remains in
the pooled<o:p></o:p>


state. The container may, but is not
required to, immediately activate the objects that were<o:p></o:p>


located by the finder using the transition
through the ejbActivate() method. 
"   
Section 10.5.3 page no 177 of EJB 2.0 <o:p></o:p>


 <o:p></o:p>


It doesnt give identity till there is
request by client. But there is cost of construction of Remote interfaces that
it return to the client for multi object finders.<o:p></o:p>


HTH<o:p></o:p>


/Ashwani
<o:p></o:p>


 <o:p></o:p>


 <o:p></o:p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<p class=MsoNormal style='margin-right:.5in;mso-margin-top-alt:auto;margin
-bottom:
12.0pt;margin-left:39.75pt;border:none;mso-border-left-alt:solid blue 1.5pt;
padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>----
-Original
Message-- -- 
From: Pradeep Kumar
[mailto:pradeepk@(protected)] 
Sent: Friday, September 19, 2003
9:30 AM 
To: J2EEPATTERNS-INTEREST@(protected)
.COM 
Subject: Re: Large finders on
entity beans refactored<o:p></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:39.75pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>While the
container is executing the finder method, it must give identities to each of
the objects (primary keys). Hence, they must be placed in the ready state,
since objects do not have any identity in the pooled state.<o:p></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:39.75pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'> <o:p
></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:39.75pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>Can
someone please clarify the statement from the specs.<o:p></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:39.75pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'> <o:p
></o:p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:75.75pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>-- --Original Message-- -- 
From: Kalra, Ashwani
[mailto:ashwani.kalra@(protected)] 
Sent: Thursday, September 18, 2003
7:28 PM 
To: J2EEPATTERNS-INTEREST@(protected)
.COM 
Subject: Re: Large finders on
entity beans refactored<o:p></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:75.75pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>
 <o:p></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:75.75pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>Here
what I read from specs 2.0<o:p></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:75.75pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>
 <o:p></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:75.75pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>
"The
instance does not move to the ready state during the execution of a finder or a
home 
method."<o:p></o:p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<p class=MsoNormal style='margin-right:.5in;mso-margin-top-alt:auto;margin
-bottom:
12.0pt;margin-left:79.5pt;border:none;mso-border-left-alt:solid blue 1.5pt;
padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>----
-Original
Message-- -- 
From: Pradeep Kumar
[mailto:pradeepk@(protected)] 
Sent: Monday, September 15, 2003
9:54 AM 
To:
J2EEPATTERNS-INTEREST@(protected) 
Subject: Re: Large finders on
entity beans refactored<o:p></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:79.5pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>I totally agree. We are
told that if we read a large amt of data via entity beans, there will be too
many entity objects in ready state. One can argue, that they will be the cached
data for subsequent reads (lets? say via find by primary key), however, to
avoid dirty reads, the container calls the EJB load method, which defeats the
purpose of caching<o:p></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:79.5pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'> <o:p></o:p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:115.5pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>-- --Original Message-- -- 
From: Katz Guy
[mailto:Guy_Katz@(protected)] 
Sent: Sunday, September 14, 2003
12:12 PM 
To:
J2EEPATTERNS-INTEREST@(protected) 
Subject: Large finders on entity
beans refactored<o:p></o:p>

<p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:.5in;margin
-bottom:
0in;margin-left:115.5pt;margin-bottom:.0001pt;border:none;mso-border-left-alt:
solid blue 1.5pt;padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>
 <o:p></o:p>

Hi; 
Going through the core patterns book. 
There is a bad practice dedicated to not using
finder methods when large result is expected but use a DAO instead. 
My understanding is that the authors want to
have a 'dual interface' for access to the same data, Modeling the data itself
as entity beans yet using DAO for the search. Is this correct? 
<o:p></o:p>

If so, wouldn't this be in contrast to resusability? Also, isnt
this a good place to put your money on vendor container optimiations?<o:p></o:p>

__ ____ ____ ____ _____ 
Guy Katz 
Software Architect, CAP
-IFS 
Comverse 
guy.katz@(protected) 
+972 3 7663686 <o:p></o:p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

DISCLAIMER: 
This message (including attachment if any) is confidential and may be
privileged. Before opening attachments please check them for viruses and
defects. MindTree Consulting Private Limited (MindTree) will not be responsible
for any viruses or defects or any forwarded attachments emanating either from
within MindTree or outside. If you have received this message by mistake please
notify the sender by return e-mail and delete this message from your system.
Any unauthorized use or dissemination of this message in whole or in part is
strictly prohibited. Please note that e-mails are susceptible to change and
MindTree shall not be liable for any improper, untimely or incomplete
transmission.
==================================================================== Companion
Site: http://www.corej2eepatterns.com J2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatterns List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing:
email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
==================================================================== Companion
Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com
/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)<o:p></o:p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

DISCLAIMER: 
This message (including attachment if any) is confidential and may be
privileged. Before opening attachments please check them for viruses and
defects. MindTree Consulting Private Limited (MindTree) will not be responsible
for any viruses or defects or any forwarded attachments emanating either from
within MindTree or outside. If you have received this message by mistake please
notify the sender by return e-mail and delete this message from your system.
Any unauthorized use or dissemination of this message in whole or in part is
strictly prohibited. Please note that e-mails are susceptible to change and
MindTree shall not be liable for any improper, untimely or incomplete
transmission. <o:p></o:p>

__ ____ ____ ____ ____ ____ ____ ____ ____ ______
___<o:p></o:p>

This message contains information that may be
privileged or confidential and is the property of the Cap Gemini Ernst &
Young Group. It is intended only for the person to whom it is addressed. If you
are not the intended recipient, you are not authorised to read, print, retain,
copy, disseminate, distribute, or use this message or any part thereof. If you
receive this message in error, please notify the sender immediately and delete
all copies of this message.<o:p></o:p>

<p class=MsoNormal style='margin-right:.5in;mso-margin-top-alt:auto;mso-margin
-bottom-alt:
auto;margin-left:39.75pt;border:none;mso-border-left-alt:solid blue 1.5pt;
padding:0in;mso-padding-alt:0in 0in 0in 4.0pt'>=============
=======================================================
Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatterns List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing:
email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
==================================================================== Companion
Site: http://www.corej2eepatterns.com J2EE BluePrints:
http://java.sun.com/blueprints/corej2eepatterns List Archive:
http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing:
email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
<o:p></o:p>

</div>

</div>

DISCLAIMER: This message (including attachment if any) is
confidential and may be privileged. Before opening attachments please check
them for viruses and defects. MindTree Consulting Private Limited (MindTree)
will not be responsible for any viruses or defects or any forwarded attachments
emanating either from within MindTree or outside. If you have received this
message by mistake please notify the sender by return e-mail and delete this
message from your system. Any unauthorized use or dissemination of this message
in whole or in part is strictly prohibited. Please note that e-mails are
susceptible to change and MindTree shall not be liable for any improper,
untimely or incomplete transmission.</body>

</html>
 

__ ____ ____ ____ ____ ____ ____ ____ ____ ____
__ __

This message contains information that may be
privileged or confidential and is the property of the Cap Gemini Ernst & Young
Group. It is intended only for the person to whom it is addressed. If you are
not the intended recipient, you are not authorised to read, print, retain, copy
, disseminate, distribute, or use this message or any part thereof. If you
receive this message in error, please notify the sender immediately and delete
all copies of this message.
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)