On Tue, 07 Oct 2014 09:45:21 -0300, Chris Mylonas
wrote:
Hi All Tapestry Ppl,
Hi!
aaa) What are the basics in firing it up? Say from a main() method,
*unmanaged* i know...i read the IoC overview :)
http://tapestry.apache.org/starting-the-ioc-registry.html. ;)
--
Thiago H. de Paula Fi
Hi,
I had this exact same question and problem, and found changing the JDK
to use 7 instead of 8 fixed it.
However, this seems to do it even when I download a snapshot of
Tapestry and run using JDK 8, is there any documentation anywhere with
any requirements and instructions on how to use JDK 8?
It's caused by asm.ClassReader. Which jvm version and tapestry version are
you using? Tapestry has only recently added support for java 8 (asm5).
This was caused by a JDK version conflict!
- Original Message -
From: John
To: users@tapestry.apache.org
Sent: Tuesday, September 02, 2014 11:08 AM
Subject: Tapestry ioc/registry startup exception?
Hi,
Any pointers on why my app won't start pls?
John
ioc.Registry Er
He still needs to manually contribute the interface-implementing services
to this single service. Still, it sounds like the closes solution.
*-*
*Muhammad Gelbana*
http://www.linkedin.com/in/mgelbana
On Sat, Feb 22, 2014 at 11:18 AM, Lance Java wrote:
> I think the "tapestry
I think the "tapestry way" of doing what you want is to make multiple
contributions to a single service and inject the single service.
On Fri, 21 Feb 2014 12:58:26 -0300, Michael Gagauz
wrote:
Is it possible in T5 to inject multiple services which implemented same
interface into array field?
I.e:
@Inject
private SomeService[] services;
No.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and deve
On Tue, 11 Feb 2014 18:16:01 -0200, Lance Java
wrote:
you must bind every actor and make sure it uses the correct scope
You could do something like this:
public void bind(ServiceBinder binder) {
Class[] actorClasses = ...;
for (Class actorClass : actorClasses) {
bin
> you must bind every actor and make sure it uses the correct scope
You could do something like this:
public void bind(ServiceBinder binder) {
Class[] actorClasses = ...;
for (Class actorClass : actorClasses) {
binder.bind(actorClass).scope("prototype");
}
}
If y
On Tue, 11 Feb 2014 15:03:21 -0200, Thilo Tanner
wrote:
Hi Thiago,
Hi!
unfortunately, it isn't that simple. I made a quick test and introduced
a bean service lifecycle. Technically it works, but the solution isn't
very elegant: you must bind every actor and make sure it uses the
corr
Thiago, every time you call ObjectLocator.getService() you get a singleton.
Every time you call ObjectLocator.autobuild() you get a new object.
ks for the input!
Thilo
From: Thiago H de Paula Figueiredo
Sent: Tuesday, February 11, 2014 17:30
To: Tapestry users
Subject: Re: Tapestry IOC / Autobuild / Advise Question
On Tue, 11 Feb 2014 13:51:13 -0200, Thilo Tanner
wrote:
> Hi Lance, h
On Tue, 11 Feb 2014 13:51:13 -0200, Thilo Tanner
wrote:
Hi Lance, hi Thiago,
Hi!
thanks a lot for your feedback. To be honest, I'm still a bit confused:
Creating a bean or prototype scope seem to be controversial, according
to older discussions:
e.g. http://web.archiveorange.com/arch
On Tue, 11 Feb 2014 13:21:20 -0200, Lance Java
wrote:
Thiago, perhaps my wording was a little ambiguous. I consider perthread
scoped services are still singletons. The proxy is a singleton (the
underlying target may not be a singleton).
I would never say that. The proxy itself may be a sing
ossible to transform an object
created by autobuild()?
http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/plastic/PlasticClass.html
Thanks again and best,
Thilo
From: Lance Java
Sent: Tuesday, February 11, 2014 16:21
To: Tapestry users
Subject: Re: Ta
Thiago, perhaps my wording was a little ambiguous. I consider perthread
scoped services are still singletons. The proxy is a singleton (the
underlying target may not be a singleton). Using autobuild creates a new
instance.
You might also want to consider implementing a custom scope (eg
"prototype") by contributing a ServiceLifecycle to ServiceLifecycleSource.
You could then mark your services with @Scope("prototype").
Take a look at PerThreadServiceLifecycle for inspiration.
On Tue, 11 Feb 2014 12:22:52 -0200, Lance Java
wrote:
Decoration is really for singleton services whereas you are using a scope
which can be compared to spring's prototype scope.
I'm sorry, Lance, but that's not correct. Decoration and advice does work
with any service defined with an int
Decoration is really for singleton services whereas you are using a scope
which can be compared to spring's prototype scope.
I think you could transform the class (via PlasticManager /
PlasticClassTransformer) prior to calling
ObjectLocator.autobuild(transformedClass)
I see what you mean Denis, thank you.
On Fri, May 31, 2013 at 10:21 AM, Denis Stepanov
wrote:
> I have tried to push exactly same idea but wasn't successful.
>
> https://issues.apache.org/jira/browse/TAP5-1842
>
> Denis
>
> May 31, 2013 v 4:16 PM, Eli Doran :
>
> > There's already a @ServiceId
I have tried to push exactly same idea but wasn't successful.
https://issues.apache.org/jira/browse/TAP5-1842
Denis
May 31, 2013 v 4:16 PM, Eli Doran :
> There's already a @ServiceId annotation to specify the ID. This isn't a
> "service" exactly, it's close enough.
>
>
> On Fri, May 31, 2013
If you derive the id from the method name, this might break backwards
compatability. I'm guessing there are a lot of startup methods called
startup()
Perhaps a new annotation is required
@OrderedStartup(id="doEarly", constraints="before:*")
public static void doStuff() { … }
@OrderedStartup(id="doStuff")
public static void doStuff() { … }
@OrderedStartup(id="doMoreStuff", constraints="after:doStuff")
public static void doMoreStuff() { … }
On
There's already a @ServiceId annotation to specify the ID. This isn't a
"service" exactly, it's close enough.
On Fri, May 31, 2013 at 10:12 AM, Lance Java wrote:
> Perhaps a new annotation is required
>
> @OrderedStartup(id="doEarly", constraints="before:*")
> public static void doStuff() { … }
Yeah, like with builder methods which use the name after "build" as the
Service ID.
For example, to have the ID "SomeTask":
> @Startup("before:SomeOtherOne")
> public void startupSomeTask() { }
On Fri, May 31, 2013 at 9:50 AM, Lance Java wrote:
> I'm not sure this would work. OrderedConfigur
I'm not sure this would work. OrderedConfiguration requires that every
entry has a unique id and @Startup does not require an id. I guess you
could use ModuleClass.methodName for the default id but it's messy.
You can always post a JIRA asking for that.
On Thu, May 30, 2013 at 12:56 PM, Eli Doran wrote:
> I am not using Tapestry web framework (which means I'd have everything in
> my App's module, and its submodules, to keep it all together.) This means
> the "other startup methods" are in other modul
I am not using Tapestry web framework (which means I'd have everything in
my App's module, and its submodules, to keep it all together.) This means
the "other startup methods" are in other modules.
I work with a lot of modules which run together in different combinations.
They contribute to the st
Thank you for sending feedback.
I am aware of the nature of FactoryDefaults/ApplicationDefaults. It's a
good system, easy to understand, and works.
I have thought about this before posting as I use something similar already
in my code. I don't have default value conflicts, however, I do
occasionall
Hi Eli,
This would be clever, but you can always have a single @Startup method that
then calls all of your other startup methods in the order you want. In
some ways, I think this is easier to read/understand. The startup order is
clearly defined in a single spot instead of having to go decipher
+1
On Mon, May 27, 2013 at 7:50 PM, Eli Doran wrote:
> I like the simplicity of using the @Startup annotation compared to the
> startup contribution method.
>
> However, it doesn't have the ability to order its execution as in the
> contribution method.
>
> It seems it would be a simple thing t
I can see one problem here -- nothing prevents you from specifying more
than one @DefaultValue and you may get a conflict too late, as far as I see
you can't control this. Have you thought about it?
On Tue, May 28, 2013 at 12:23 AM, Eli Doran wrote:
> I've used @Symbols a lot. I appreciate its
Having an optional default value on @Symbol seems useful to me.
On Mon, May 27, 2013 at 4:42 PM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Mon, 27 May 2013 17:23:36 -0300, Eli Doran wrote:
>
> I've used @Symbols a lot. I appreciate its flexibility and coercion
>> ability.
>
On Mon, 27 May 2013 17:23:36 -0300, Eli Doran wrote:
I've used @Symbols a lot. I appreciate its flexibility and coercion
ability.
I started programming around it though and instead accessing SymbolSource
and TypeCoercer directly because it is missing the ability to specify a
default value, a
On Wed, Sep 12, 2012 at 6:02 PM, Thiago H de Paula Figueiredo
wrote:
> On Wed, 12 Sep 2012 17:05:51 -0300, Muhammad Gelbana
> wrote:
>
>>>
>>> HiveMind just makes me think of StarCraft. ;-)
>>
>>
>> Exactly eheheh :D
>
>
> No one thought of the Borg hive mind in Star Trek?
I very much did, when
On Wed, 12 Sep 2012 17:05:51 -0300, Muhammad Gelbana
wrote:
HiveMind just makes me think of StarCraft. ;-)
Exactly eheheh :D
No one thought of the Borg hive mind in Star Trek?
--
Thiago H. de Paula Figueiredo
-
To unsu
On Wed, 12 Sep 2012 13:26:09 -0300, Howard Lewis Ship
wrote:
Maybe we could resurrect the HiveMind name? I always loved that name!
I've just had a very bad idea: Unicorn IoC! It matches the Tapestry logo
and searching for 'unicorn ioc' in Google has no relevant results . . .
--
Thiago
>
> HiveMind just makes me think of StarCraft. ;-)
Exactly eheheh :D
On Wed, Sep 12, 2012 at 8:11 PM, Lenny Primak wrote:
> HiveMind always had negative connotations in my mind as well.
> I say de-emphasize Tapestry in Tapestry-IoC.
> Just call it IoC.
>
> I hate Spring myself, and anything that
HiveMind always had negative connotations in my mind as well.
I say de-emphasize Tapestry in Tapestry-IoC.
Just call it IoC.
I hate Spring myself, and anything that gets people off it is a good thing IMHO
On Sep 12, 2012, at 1:52 PM, Daniel Jue wrote:
> I'd say keep the same name but market the
I'd say keep the same name but market the IOC more heavily, with tutorials
and demos (a quickstart, perhaps) of it being used in a non web app. (I
don't think this is out there, right? If it is, it wasn't in-my-face
enough. :-) ) A T5 IOC quickstart might work well with an Apache Shiro
example,
On Wed, Sep 12, 2012 at 2:59 AM, Lance Java wrote:
> I've often had a conversation like this in the workplace:
>
> colleague: Let's start a new spring project
> me: I hate spring, how about we use Tapestry IOC instead?
> colleague: Tapestry, isn't that a web framework?
> me: Well
On startup, Tapestry stores the Registry into the ServletContext. If
you can get to the servlet context, you can get the Registry.
The key is org.apache.tapestry5.application-registry or use the
constant TapestryFilter.REGISTRY_CONTEXT_NAME.
On Thu, Sep 8, 2011 at 8:59 AM, Wechsung, Wulf wrote:
On Thu, 08 Sep 2011 12:59:09 -0300, Wechsung, Wulf
wrote:
Hello Guys,
Hi!
I'm wondering, in a Tapestry Webapp scenario, how is it possible to
obtain a reference to the IOC Registry for a (or all) currently loaded
module(s). I know about RegistryBuilder but build() says to only call it
Oh my - a simple @InjectService did the trick. Thank you, everything
works great now.
Side node: Since the old version did sometimes work I just hoped for
your answer and continued working. In this process I added a logger to
the contribution method:
public static void
contributeTestSymbolPro
Well, the good news is that Alias is going away in 5.3 :-)
Contributing to TypeCoercer and SymbolSource can, too easily, lead to
these unintentional circular dependencies, as type coercion and
symbols are often present in other contributions.
public static void
contributeTestSymbolProvider(Con
On Tue, 07 Jun 2011 14:47:10 -0300, Dmitriy Vsekhvalnov
wrote:
did i get you right, that i can simply inject ObjectLocator service to my
Quartz JobFactory and instantiate jobs via autobuild()
I mean sources saying all dependencies will be injected.
Yes. JavaDoc: Autobuilds a class by findin
did i get you right, that i can simply inject ObjectLocator service to my
Quartz JobFactory and instantiate jobs via autobuild()
I mean sources saying all dependencies will be injected.
On Tue, Jun 7, 2011 at 8:20 PM, Howard Lewis Ship wrote:
> Unfortunately, Tapestry is not Spring :-) The p
Unfortunately, Tapestry is not Spring :-) The proxy you get back from
a direct or indrect call to getService() is always global, though in
the case of the perthread scope, that core service implementation is
... another proxy that manages and delegates to the per-thread
instance.
I think you need
i was hoping someone already did it :)
Last time i was trying to do it with Hivemind, proxy created a new instance
every method call, and this is not what i want. I mostly likely want
no-proxy, but just new instance.
On Tue, Jun 7, 2011 at 6:32 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.c
On Tue, 07 Jun 2011 10:47:23 -0300, Dmitriy Vsekhvalnov
wrote:
Hi all,
Hi!
is it possible to have services bound with Bean scope? I'm using
Quartz scheduler and my jobs are actually services bound in AppModule
with all
dependency injection and so on.
But i want different instance
> I haven't used this library yet, so I don't know if it needs
> SpringModule
> or not. I guess it does, as Howard wrotes it and SpringModule is
> there.
> But that's just a guess. :)
No, it doesn't use it, it just happened to be in my classpath.
On Fri, 2011-01-07 at 09:08 -0200, Thiago H.
On Fri, 07 Jan 2011 07:46:39 -0200, Joel Halbert
wrote:
Actually - it all stemmed from me just wanting to exclude the
SpringModule when using the tapx templating library for sending html
emails!
I haven't used this library yet, so I don't know if it needs SpringModule
or not. I guess it d
Actually - it all stemmed from me just wanting to exclude the
SpringModule when using the tapx templating library for sending html
emails!
Since that's a standalone app that just uses tapx & tap-ioc (no web
component) it just got me thinking about using Tap-IOC for my other
standalone, non Tapest
> Again, it doesn't seem right to have to consider what are effectively runtime
> deployment configuration options when building an application into a jar.
This is funny because I thought that is exactly what you are trying to
do. If you are going to exclude modules from a deployment but don't
wa
On Thu, Jan 6, 2011 at 8:45 AM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Thu, 06 Jan 2011 14:37:43 -0200, Joel Halbert
> wrote:
>
> > > - if you have lots of modules, which a client may want to selectively
>>> > > enable, do not declare them in the manifest, but instead le
It needs to be documented. Maybe I'll find time soon. I really need to
finish the tutorial itself!
It is very useful.
I use it to separate my production configuration from my test configuration.
On Thu, Jan 6, 2011 at 7:46 AM, Josh Canfield wrote:
> If you provide a jar with 100 modules that
On Thu, 06 Jan 2011 14:37:43 -0200, Joel Halbert
wrote:
> > - if you have lots of modules, which a client may want to
selectively
> > enable, do not declare them in the manifest, but instead let the
client
> > use the tapestry.modules sys property to selectively enabl
But that's sort of
> > > - if you have lots of modules, which a client may want to selectively
> > > enable, do not declare them in the manifest, but instead let the client
> > > use the tapestry.modules sys property to selectively enabl
But that's sort of my point - configuring IOC via a system property doesn't
s
On Thu, 06 Jan 2011 14:09:02 -0200, Joel Halbert
wrote:
So if I understand correctly:
- the only way to disable modules that are specified in the manifest is
to remove the jar from the classpath
Wrong. See
http://tapestry.1045711.n5.nabble.com/T5-disable-loading-specified-module-td243111
So if I understand correctly:
- the only way to disable modules that are specified in the manifest is
to remove the jar from the classpath
- if you have lots of modules, which a client may want to selectively
enable, do not declare them in the manifest, but instead let the client
use the tapestry
If you provide a jar with 100 modules that can be enabled/disabled
then don't provide the manifest entry and resort to providing modules
via tapestry.modules system property...
> Searching the mailing list archives I've found this thread with a solution
> for disabling the autoloading of given mod
On Thu, 06 Jan 2011 13:07:34 -0200, Joel Halbert
wrote:
why cant you take the jar from the classpath?
This is what I have done, but it strikes me as quite a blunt instrument
to use for configuring an application. Does it really mean you need a
jar per service, if the user of the jar might w
> why cant you take the jar from the classpath?
This is what I have done, but it strikes me as quite a blunt instrument
to use for configuring an application. Does it really mean you need a
jar per service, if the user of the jar might want to selectively enable
some of the services but not other
That quote doesn't help because its in the manifest of the jar you want to
exclude... why cant you take the jar from the classpath?
On Jan 6, 2011 6:53 AM, "Josh Canfield" wrote:
> From the link; "Module autoloading isn't 100% free ... you must tell
> Tapestry IoC where the modules to load are loc
>From the link; "Module autoloading isn't 100% free ... you must tell
Tapestry IoC where the modules to load are located, which can be done via a
Manifest file entry, or via an annotation."
I don't believe being in the classpath is enough. I'm not sure there is a
way to prevent a dependent module
Good idea,I had the same problem.
2009/8/17 Sergey Didenko
> Hi,
>
> What do you think about dedicated annotations that are alternative to
> buildXXX() and contributeXXX() name convention?
>
> I changed service names a few times and forgot to update my build and
> contribute methods.
>
> If I wo
Em Thu, 06 Aug 2009 04:32:04 -0300, Sebastian Hennebrueder
escreveu:
Hmm,
in that case a getDelegate method could return null or the Proxy or ask
the proxy for getDelegate.
+1 to that. Annotation-driven decoration/advising is severely impaired
without getting access to the service imple
Hmm,
in that case a getDelegate method could return null or the Proxy or ask
the proxy for getDelegate.
Howard Lewis Ship schrieb:
It might be possible to advise the interface. When advising, you may
be layering advice upon a proxy to the service, in which case the
service interface is the bes
It might be possible to advise the interface. When advising, you may
be layering advice upon a proxy to the service, in which case the
service interface is the best that is known.
The latter case applies to advising a service that has a different
scope than the default, singleton.
On Wed, Aug 5,
>
>> -Original Message-
>> From: Howard Lewis Ship [mailto:hls...@gmail.com]
>> Sent: Thursday, November 20, 2008 12:16
>> To: Tapestry users
>> Subject: Re: Tapestry-IoC: binding service without code, just convention
>> over configuration
>>
>&
7;t know how you manage to actually close them!
Jonathan
> -Original Message-
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 20, 2008 12:16
> To: Tapestry users
> Subject: Re: Tapestry-IoC: binding service without code, just convention
> o
>
> That's one of the reasons I wrote the Ars Machina Generic DAO, Generic
> DAO-Hibernate and Generic Controller: all the common methods (findAll,
> findById, save, update, delete, findByExample, etc) are already written. I
> don't have to rewrite them for every entity class.
My generic dao is p
Em Thu, 20 Nov 2008 15:28:02 -0300, Thiago H. de Paula Figueiredo
<[EMAIL PROTECTED]> escreveu:
As far as I know, I cannot put the @CommitAfter method in one IoC
service and have its calls wrapped in a transaction, just components and
pages methods. If I'm wrong, I'll use Tapestry-Hibernate.
Em Thu, 20 Nov 2008 14:14:59 -0300, Howard Lewis Ship <[EMAIL PROTECTED]>
escreveu:
I think Tapestry makes it easier to separate your business logic out
as IoC services or even Spring beans. It's easier to inject a service
or bean in Tapestry than in any framework I'm aware of.
I completely
Em Thu, 20 Nov 2008 14:16:33 -0300, Jonathan Barker
<[EMAIL PROTECTED]> escreveu:
Ah, I had to jump in.
Everybody is invited!
I like using business services that keep data access code out of my
pages. That part feels good.
So do I! :)
Unfortunately, that often means that a findAll() i
w! In the meantime,
> I'll settle for keeping Session out of my pages.
>
> Jonathan
>
>
>> -Original Message-
>> From: Chris Lewis [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, November 20, 2008 11:42
>> To: Tapestry users
>> Subject: Re: Tapest
I think Tapestry makes it easier to separate your business logic out
as IoC services or even Spring beans. It's easier to inject a service
or bean in Tapestry than in any framework I'm aware of. My of the
examples, demos or prototypes do intentionally blur the layers a bit,
but you are anything b
settle for keeping Session out of my pages.
Jonathan
> -Original Message-
> From: Chris Lewis [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 20, 2008 11:42
> To: Tapestry users
> Subject: Re: Tapestry-IoC: binding service without code, just convention
> over config
One more example . . .
Em Thu, 20 Nov 2008 14:59:05 -0300, Thiago H. de Paula Figueiredo
<[EMAIL PROTECTED]> escreveu:
This is a common confusion: there is the controller in the MVC pattern
and the controller in the 3-tier architecture, and both are different
things. A controller in MVC,
Em Thu, 20 Nov 2008 13:41:46 -0300, Chris Lewis
<[EMAIL PROTECTED]> escreveu:
Thanks for the input Thiago.
All discussions are good discussions. :)
I'm curious about your reasoning for
avoiding tapestry-hibernate. I use it for it's value encoder and primary
key encoder auto wiring, and tha
Thanks for the input Thiago. I'm curious about your reasoning for
avoiding tapestry-hibernate. I use it for it's value encoder and primary
key encoder auto wiring, and that's pretty much it. I avoid injecting
Session into pages, and I assume that's the practice you specifically
are avoiding in the
> I'm thinking of not even have that binder.bind() call, automatically
binding services located in packages defined by some convention.
Very interesting idea. This mechanism could be something similar to Spring's
classpath scanning for managed components:
http://static.springframework.org/spring/
Em Wed, 19 Nov 2008 17:37:48 -0300, Chris Lewis
<[EMAIL PROTECTED]> escreveu:
Hi Thiago,
Hi, Chris!
Out of architectural curiosity, what do you use a UserController for in
your example?
I'm a strong supporter of n-tier architectures, so the view layer (in this
case, Tapestry) does no b
Hi Thiago,
Out of architectural curiosity, what do you use a UserController for in
your example?
Thiago H. de Paula Figueiredo wrote:
> Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship
> <[EMAIL PROTECTED]> escreveu:
>
>> Interesting idea. You could probably put something together around
>>
Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship <[EMAIL PROTECTED]>
escreveu:
Interesting idea. You could probably put something together around
ClassNameLocator, i.e., a wrapper that given package names, find
interfaces inside those packages that have matching Impl classes. i.e.
publi
Em Wed, 19 Nov 2008 15:31:16 -0300, Howard Lewis Ship <[EMAIL PROTECTED]>
escreveu:
Interesting idea. You could probably put something together around
ClassNameLocator, i.e., a wrapper that given package names, find
interfaces inside those packages that have matching Impl classes. i.e.
publi
Interesting idea. You could probably put something together around
ClassNameLocator, i.e., a wrapper that given package names, find
interfaces inside those packages that have matching Impl classes. i.e.
public static void bind(ServiceBinder binder)
{
new AutoServiceBinder("my.package.root").bin
Sorry !!!
Same problem as described there due to the javassist version :
http://mail-archives.apache.org/mod_mbox/tapestry-users/200705.mbox/[EMAIL
PROTECTED]
Stephane
Stephane Decleire a écrit :
Here is what i get when i try to launch my Tap 5.0.6 application from
Eclipse on Jetty 5.1.12 (by
On 5/9/07, Ognen Ivanovski <[EMAIL PROTECTED]> wrote:
Hi there!
I'm very impatient to get my hands on tapestry 5, especially the IUC
container. I really like the major points there. However, some remarks:
1. having the IOC container recognize the builder/contributor methods
by method name is c
89 matches
Mail list logo
