Check out this framework. We're currently using it and it does the job
quite nicely.
http://opensymphony.com/propertyset/
Hope it helps,
Tim
-
To make the coding a little easier we just added in one extra class file
"SettingsProxy" which allowed settings retrieval like this:
SettingsPr
[Just got Jon's email as I typed this, so I guess it's academic, but still
interesting...]
> -Original Message-
> From: Marc Zampetti [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 10, 2002 10:15 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-user] Design
I'm not sure I understand the desire to not have the key in a
persistence store. This would mean that if your systems (or jBoss)
crashes, your site is unusable until a human being inputs a new key. If
you are worried about putting the stuff on a Internet-accessible
machine, put another copy of
How about using an entity bean against a separate data source pointing at a
memory DB such as hypersonic? You could configure it not to cache, then when
the process died, your single data entry would go with it. To prime the db,
the operator would hit an operator page that also had access to tha
Some advantages of session beans:
1.) Access via RMI. No need for a web server. You can use a Java
thin-client approach. The client is mainly user-interface code. The
session beans contain
some business logic and make use of data access objects that interface to
your legacy application. Rath
Tim Yates wrote:
> Yeah, the reason we do it this way (and not via HTTP sessions or cookies),
> is that it was decided early on that it should be possible to style the site
> differently dependant on the device that was accessing it, and we couldn't
> guarantee that storing the HTTPSession, or us
2001 11:34 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Design Question...
another way to approach this is through the datbase itself, writing a
trigger to remove the data and setting a schedule for processing. most
modern rdbms systems have similar implementations
- Original Me
lt;[EMAIL PROTECTED]>
Sent: Tuesday, July 31, 2001 3:15 AM
Subject: Re: [JBoss-user] Design Question...
> Hey Tim,
>
> If I correctly understand your qutestion, this is more of a servlet type
session management issue. Take a look at the
javax.servlet.http.HttpSessionBindingListen
Hey Tim,
If I correctly understand your qutestion, this is more of a servlet type session
management issue. Take a look at the javax.servlet.http.HttpSessionBindingListener
interface. It's basically a callback interface for when a session expires. Objects
in the session, that implement the
rk on any
of the four major browsing devices...
- Original Message -
From: Mike Abney <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 30, 2001 5:28 PM
Subject: Re: [JBoss-user] Design Question...
> Sorry, just re-read this. So... you're making your own
> When a user hits the site, they get allocated a unique 48 character
session
> ID (allocated by me). If they then login, I tie that sessionId to a
userId
> (both rows in seperate tables)
>
> But I have a design question... They can log-out, but many do not
> (obviously), so what would be the be
This question is more servlet-interest oriented than JBoss oriented. You
might want to check out that mailing list.
(http://archives.java.sun.com/archives/servlet-interest.html)
The typical way I have handled this in the past is to put the userId (if not
the entire User*) into the HTTPSession whe
Sorry, by "the site", I meant "our website"
- Original Message -
From: Tim Yates <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 30, 2001 4:45 PM
Subject: [JBoss-user] Design Question...
> When a user hits the site, they get allocated a unique 48 character
session
> ID (a
: [JBoss-user] Design question - Singleton
The EJB spec forbids an enterprise Bean to use read/write static fields.
This restriction is part of the contract with the EJB Container to control
the bean lifecycle, e.g. by transparently distributing bean instances across
multiple JVMs. I understand
The EJB spec forbids an enterprise Bean to use read/write static fields. This
restriction is part of the contract with the EJB Container to control the bean
lifecycle, e.g. by transparently distributing bean instances across multiple JVMs. I
understand GemStone was big on spawning JVMs.
The st
]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, July 05, 2001 12:23 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [JBoss-user] Design question - Singleton
It sounds like there is a problem with your design if you are trying to do
this - the EJB
Hi,
is it not possible to have a static field in the Session Bean, I mean it is
not made persistent anyway.
Have you tried this approach with the static field ?
Frank
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/li
It sounds like there is a problem with your design if you are trying to do
this - the EJB container controls all instance creation, so you can't
really create a true Singleton bean.
What are you trying to do? There are many other ways to get Singleton-like
functionality with EJBs. I'm assuming t
Adam Young wrote:
> If you want to make it read only, will JBoss allow you to write the
> remote interface such that it only has getters?The M-H book suggests
> not even exposing the remote interface for enitity beans. Certainly it
> would be preferable to have on the getters available to
If you want to make it read only, will JBoss allow you to write the
remote interface such that it only has getters?The M-H book suggests
not even exposing the remote interface for enitity beans. Certainly it
would be preferable to have on the getters available to most clients.
[EMAIL PR
d the value objects?
Hunter
> From: "DeGreef, Chris J. (AIT)" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> Date: Wed, 16 May 2001 15:39:04 -0400
> To: "'[EMAIL PROTECTED]'"<[EMAIL PROTECTED]>
> Subject: RE: [JBoss-user] Design Ques
|Something to note. I found that "useBean" is kind of misleading for EJB
|developers because it doesn't refer to Entreprise Beans to me. I
sure does refers to EJB to me, javabeans as EJB is a standard pattern (hide
the EJB semantics),
marc
___
JBo
Chris,
Yes I did experiment this approach and it worked great. Many people may think
we are adding too many layers to accomplish the tasks but I believe this
approach gives a very clean separation between the biz logic and presentation
layers.
Something to note. I found that "useBean" is kind o
I have had good luck with a similar design. Here is what I do in cases like
this. Most of this was found by reading articles / books and trial and
error.
In a JSP file I use the "useBean" to create / find a bean that resides in
the same VM as the servlet engine. This bean follows the command p
Hunter Hillegas wrote:
> Okay... Starting the design on my first ever EJB/JBoss project. It's only
> going to be accessible via the Web...
>
> I want to make sure I make an educated decision on the design.
>
> This is what I'm thinking:
>
> Requests come in via a servlet, which invokes methods
25 matches
Mail list logo
