The default behaviour of Tapestry-IOC is that a service is a singleton. In
other words only a single instance is created and every time the same
instance is injected. So in your case, different classes will share the
same EventTracker service instance, and they will be able to see the same
events.
Hi,
By default services are singletons, which means all injections reference
the same object, so all your events will be available at every injection.
You can read about defining service scopes here:
http://tapestry.apache.org/defining-tapestry-ioc-services.html
On Thursday, October 5, 2017, Tyl
Question about Tapestry's IoC system. Let's pretend I register a service
called EventTracker.java. EventTracker has a private List field containing
a list of Events, a method to add those events, and a method to retrieve
those events. Now let's say I have another class that @Inject's that
EventT
"
To: "Tapestry users"
Sent: Wednesday, 11 February, 2009 17:57:20 GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: IoC question - introducing a time delay in an ASO
Peter Stavrinides wrote:
> I use an ASO as a token when signing users in, I use this small method
> to
Peter Stavrinides wrote:
I use an ASO as a token when signing users in, I use this small method
to introduce a time delay (if there are multiple failed attempts, I
increase the delay):
It would be an option to store server side when a person/system is
allowed another try to login and assure all
e.hal...@gmail.com]
Sent: February-11-09 10:32 AM
To: Tapestry users
Subject: Re: IoC question - introducing a time delay in an ASO
What happens in a clustered environment?
Tapestry services aren't part of normal HTTP session clustering.
Olle
2009/2/11 Thiago H. de Paula Figueiredo
> O
;Tapestry users"
Sent: Wednesday, 11 February, 2009 15:07:33 GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: RE: IoC question - introducing a time delay in an ASO
Hello,
I am not him:)(if that makes sense:) but I am doing the same thing right
now.
I am using the database not to slow c
._lastcheck = lastcheck;
}
}
Thanks,
--James
-Original Message-
From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com]
Sent: February-11-09 9:18 AM
To: Tapestry users
Subject: Re: IoC question - introducing a time delay in an ASO
On Wed, Feb 11, 2009 at 11:16 AM, Ulrich Stärk wr
What happens in a clustered environment?
Tapestry services aren't part of normal HTTP session clustering.
Olle
2009/2/11 Thiago H. de Paula Figueiredo
> On Wed, Feb 11, 2009 at 11:16 AM, Ulrich Stärk wrote:
> > Something like a singleton tapestry service with an access-synchronized
> map
>
On Wed, Feb 11, 2009 at 11:16 AM, Ulrich Stärk wrote:
> Something like a singleton tapestry service with an access-synchronized map
> inside maybe?
That's what I'd do.
James: sorry for mistaking your message as someone else's. :)
--
Thiago
--
thiag...@gmail.com]
Sent: February-11-09 8:52 AM
To: Tapestry users
Subject: Re: IoC question - introducing a time delay in an ASO
On Wed, Feb 11, 2009 at 10:46 AM, James Sherwood
wrote:
Hello,
Hi!
Doesn't most dictionary style attacks create a new request each time
therefore creating
reate an application wide map(object) in T5?
Sorry for kind of hijacking your thread Peter:)
--James
-Original Message-
From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com]
Sent: February-11-09 8:52 AM
To: Tapestry users
Subject: Re: IoC question - introducing a time delay in a
Paula Figueiredo [mailto:thiag...@gmail.com]
Sent: February-11-09 8:14 AM
To: Tapestry users
Subject: Re: IoC question - introducing a time delay in an ASO
On Wed, Feb 11, 2009 at 9:49 AM, Peter Stavrinides
wrote:
> I use an ASO as a token when signing users in, I use this small method to
int
On Wed, Feb 11, 2009 at 10:46 AM, James Sherwood
wrote:
> Hello,
Hi!
> Doesn't most dictionary style attacks create a new request each time
> therefore creating a new ASO? Kind of like closing your browser and
> reopening it each time?
They are done by bots (programs), not people, so I guess yo
On Wed, Feb 11, 2009 at 9:49 AM, Peter Stavrinides
wrote:
> I use an ASO as a token when signing users in, I use this small method to
> introduce a time delay (if there are multiple failed attempts, I increase the
> delay):
Your code doesn't delay the ASO, it delays the request processing. ;)
I
ry users"
Sent: Wednesday, 11 February, 2009 13:04:17 GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: IoC question - introducing a time delay in an ASO
On Wed, Feb 11, 2009 at 8:25 AM, Peter Stavrinides
wrote:
> Hi everyone,
Hi!
> What are the effects of using T
On Wed, Feb 11, 2009 at 8:25 AM, Peter Stavrinides
wrote:
> Hi everyone,
Hi!
> What are the effects of using Thread.sleep(myInterval) in an ASO? My
> understanding is that each user receives a separate instance of the ASO, but
> not
> necessarily on a separate thread, right?
Each user receive
Hi everyone,
What are the effects of using Thread.sleep(myInterval) in an ASO? My
understanding is that each user receives a separate instance of the ASO, but
not necessarily on a separate thread, right?
If this is true then what happens after Thread.sleep is active, and the next
user asks for
though I have no idea what you're trying to do :)
have you considered using decorators? Those work well in most cases
where you want to "override" a default service, and it always seems
easier to understand..
[EMAIL PROTECTED] wrote:
This happens to me in one Tapestry5 project when I start
This happens to me in one Tapestry5 project when I start it using the Jetty
plugin and eclipse.
If I start it up using mvn jetty:run, this does not occur - so it might be
something with Maven or the classpath as well.
Sun, 21 Sep 2008 23:41:37 -0700
hi michael,
happened to me several time
8 19:32
Bitte antworten an
"Tapestry users"
An
users@tapestry.apache.org
Kopie
Thema
IoC Question with Alias
Hi,
I have a problem with the contributions to the alias service. The
AppModule is ...
public static void bind( ServiceBinder binder ) {
binder.bind( SiteDispat
Hi,
I have a problem with the contributions to the alias service. The
AppModule is ...
public static void bind( ServiceBinder binder ) {
binder.bind( SiteDispatcher.class ).withId( "SiteDispatcher" );
binder.bind( SiteServiceImpl.class ).withId( "SiteService" );
binder.bind( HttpdReq
Plenty of reasons to have different service implementations per
environment.
A big one for me is authentication. Same app may have different
authentication strategies depending on environment. LDAP here, db-
backed there, simple (or none) for development, etc.
There are a number of ways tha
On option is inside your contributeMasterDispatcher() contribution
method, you decide then and there which of two versions to contribute:
a development mode version or a production mode version. You can
inject
@Symbol(TapestryConstants.PRODUCTION_MODE_SYMBOL) boolean productionMode
into the m
I don't think so. The problem I am trying to solve in this case is that
I have a Dispatcher that performs authentication and authorization in
the Tapestry request pipeline (I'm very new to T5 so I hope I'm using
sane terms there). In the dev environment I need the implementation to
not have externa
Glenn,
What requires you to have separate implementations for each
environment? Is it configuration data that you could move into a
properties file that lives the in the classpath of your container?
Ben
On Fri, Mar 21, 2008 at 4:02 PM, Glenn Sudduth <[EMAIL PROTECTED]> wrote:
> (This seems like
(This seems like a pretty basic question, but I haven't been able to
ferret out the answer so here goes ...)
What is a good way to have Tapestry 5 IoC determine which implementation
of a particular service to load at runtime? With Spring I accomplish
this by creating multiple versions of the bean
27 matches
Mail list logo
