Re: Deadlock in IOC (ConcurrentBarrier vs JustInTimeObjectCreator)
On Mon, Aug 17, 2020 at 6:42 AM Oliver Kaiser wrote: > sure; that seems to fix it > Thank *you* for doing almost the whole work here: spotting the issue, creating a test case, suggesting the fix (which was exactly what you suggested) then confirming it. :) > > thank you, > Oliver > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
Re: Deadlock in IOC (ConcurrentBarrier vs JustInTimeObjectCreator)
On 08/16/2020 10:20 PM, Thiago H. de Paula Figueiredo wrote: I've committed a fix using your code as a test and uploaded a new Tapestry 5.6.0 snapshot to the ASF snapshot repository at https://repository.apache.org/content/groups/snapshots/. Could you please test on your end too? Thanks in advance. sure; that seems to fix it thank you, Oliver - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Deadlock in IOC (ConcurrentBarrier vs JustInTimeObjectCreator)
Hello, Oliver!
I've committed a fix using your code as a test and uploaded a new Tapestry
5.6.0 snapshot to the ASF snapshot repository at
https://repository.apache.org/content/groups/snapshots/. Could you please
test on your end too? Thanks in advance.
On Sat, Aug 15, 2020 at 3:08 PM Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Hello!
>
> It's a very specific corner case. Please create a JIRA ticket and I'll try
> to fix it. Thanks for posting and investigating!
>
> On Thu, Jul 30, 2020 at 1:44 PM Oliver Kaiser
> wrote:
>
>> Hi everyone,
>>
>>
>> we recently found a strange deadlock problem; first seemed to be related
>> to switching from 5.5.0-beta-1 to 5.5.0, at least
>> in the full application it was easy to reproduce with the latter but (in
>> a few manual tests) not with the beta.
>>
>> after trying to reduce it to a minimal test case… it can be triggered
>> with either (and 5.4.x); maybe in the "real" code the calls
>> take long enough to avoid the data race or at least make it unlikely.
>>
>>
>> on to the questions:
>>
>> * has anyone seen something like this before? closest bug i can find is:
>> https://issues.apache.org/jira/browse/TAPESTRY-2561
>>
>> * is this likely related to registry startup? kinda afraid of same
>> situation during normal operations, though once most/all services
>> are realized everything should be fine
>>
>> thanks for reading & any hints you can offer
>>
>> Regards,
>> Oliver
>>
>>
>> it appears all of the following is required:
>>
>> * a builder method for a simple class (not a service); with some kind of
>> call to IOC (inject anything)
>>
>>public static SomeClass build(@Inject @Symbol("some.symbol") String
>> uri) {
>> return new SomeClass();
>>}
>>
>>
>> * this class is a dependency for a shared service:
>>
>> public class SharedImpl implements Shared {
>>
>>public SharedImpl(SomeClass iDoNothing) {
>>}
>>
>>
>> * two services marked as eager-load; both require the shared service
>>
>>public static void bind(ServiceBinder binder) {
>> binder.bind(JobAdder.class, JobAdderImpl.class).eagerLoad();
>> binder.bind(Other.class, OtherImpl.class).eagerLoad();
>> binder.bind(Shared.class, SharedImpl.class);
>>}
>>
>>
>> * JobAdder c-tor adds Runnable(s) to PeriodicExecutor
>>
>>public JobAdderImpl(List parts, PeriodicExecutor
>> exec) {
>> LOG.info("Blocked here?");
>>
>> for (RunnableJobData p : parts) {
>>exec.addJob(new ImmediateStartIntervalSchedule(1000 * 60),
>> p.name, p.run);
>> }
>>}
>>
>>
>> * the Runnable and OtherImpl (c-tor) call the shared service (instances
>> are realized)
>>
>>@Contribute(JobAdder.class)
>>public static void contributeJobParts(OrderedConfiguration conf,
>> Shared something) {
>>
>> conf.add("abc", new RunnableJobData("abc", () -> {
>>LOG.info("starting job");
>>something.doFoo();
>>
>>
>>public class OtherImpl implements Other {
>>
>> public OtherImpl(Shared xx) {
>>xx.doFoo();
>>
>>
>> * the jobs start immediately (no initial delay)
>>
>>public class ImmediateStartIntervalSchedule extends IntervalSchedule {
>>
>> public ImmediateStartIntervalSchedule(final long interval) {
>>super(interval);
>> }
>>
>> @Override
>> public long firstExecution() {
>>return System.currentTimeMillis();
>> }
>>
>>
>>
>> probably the easiest fix (for us) is to avoid the immediate execution of
>> periodic jobs while "RegistryImpl.performRegistryStartup"
>> is still running on the main thread; e.g. adding the jobs from a
>> @Startup method seems to work ok
>>
>> maybe PeriodicExecutorImpl::start should be called from @Startup instead
>> of @PostInjection (assuming startup methods are called after the
>> registry is done, while @PostInjection is called earlier?)
>>
>>
>> in the trace below both threads "hold" a R-lock, one also has (upgraded
>> to) W, the second blocks on W … that seems wrong
>>
>>
>> https://github.com/apache/tapestry-5/blob/master/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/util/ConcurrentBarrier.java#L54
>> maybe reentra
Re: Deadlock in IOC (ConcurrentBarrier vs JustInTimeObjectCreator)
Hello!
It's a very specific corner case. Please create a JIRA ticket and I'll try
to fix it. Thanks for posting and investigating!
On Thu, Jul 30, 2020 at 1:44 PM Oliver Kaiser
wrote:
> Hi everyone,
>
>
> we recently found a strange deadlock problem; first seemed to be related
> to switching from 5.5.0-beta-1 to 5.5.0, at least
> in the full application it was easy to reproduce with the latter but (in
> a few manual tests) not with the beta.
>
> after trying to reduce it to a minimal test case… it can be triggered
> with either (and 5.4.x); maybe in the "real" code the calls
> take long enough to avoid the data race or at least make it unlikely.
>
>
> on to the questions:
>
> * has anyone seen something like this before? closest bug i can find is:
> https://issues.apache.org/jira/browse/TAPESTRY-2561
>
> * is this likely related to registry startup? kinda afraid of same
> situation during normal operations, though once most/all services
> are realized everything should be fine
>
> thanks for reading & any hints you can offer
>
> Regards,
> Oliver
>
>
> it appears all of the following is required:
>
> * a builder method for a simple class (not a service); with some kind of
> call to IOC (inject anything)
>
>public static SomeClass build(@Inject @Symbol("some.symbol") String
> uri) {
> return new SomeClass();
>}
>
>
> * this class is a dependency for a shared service:
>
> public class SharedImpl implements Shared {
>
>public SharedImpl(SomeClass iDoNothing) {
>}
>
>
> * two services marked as eager-load; both require the shared service
>
>public static void bind(ServiceBinder binder) {
> binder.bind(JobAdder.class, JobAdderImpl.class).eagerLoad();
> binder.bind(Other.class, OtherImpl.class).eagerLoad();
> binder.bind(Shared.class, SharedImpl.class);
>}
>
>
> * JobAdder c-tor adds Runnable(s) to PeriodicExecutor
>
>public JobAdderImpl(List parts, PeriodicExecutor exec)
> {
> LOG.info("Blocked here?");
>
> for (RunnableJobData p : parts) {
>exec.addJob(new ImmediateStartIntervalSchedule(1000 * 60),
> p.name, p.run);
> }
>}
>
>
> * the Runnable and OtherImpl (c-tor) call the shared service (instances
> are realized)
>
>@Contribute(JobAdder.class)
>public static void contributeJobParts(OrderedConfiguration conf,
> Shared something) {
>
> conf.add("abc", new RunnableJobData("abc", () -> {
>LOG.info("starting job");
>something.doFoo();
>
>
>public class OtherImpl implements Other {
>
> public OtherImpl(Shared xx) {
>xx.doFoo();
>
>
> * the jobs start immediately (no initial delay)
>
>public class ImmediateStartIntervalSchedule extends IntervalSchedule {
>
> public ImmediateStartIntervalSchedule(final long interval) {
>super(interval);
> }
>
> @Override
> public long firstExecution() {
>return System.currentTimeMillis();
> }
>
>
>
> probably the easiest fix (for us) is to avoid the immediate execution of
> periodic jobs while "RegistryImpl.performRegistryStartup"
> is still running on the main thread; e.g. adding the jobs from a
> @Startup method seems to work ok
>
> maybe PeriodicExecutorImpl::start should be called from @Startup instead
> of @PostInjection (assuming startup methods are called after the
> registry is done, while @PostInjection is called earlier?)
>
>
> in the trace below both threads "hold" a R-lock, one also has (upgraded
> to) W, the second blocks on W … that seems wrong
>
>
> https://github.com/apache/tapestry-5/blob/master/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/util/ConcurrentBarrier.java#L54
> maybe reentrancy; but i'm not sure about the "upgrade R to W" logic
>
>
>
> here is the test source: https://easyupload.io/xzy6j1
>
>
> Found one Java-level deadlock:
> =
> "main":
>waiting to lock monitor 0x7f7f38008b80 (object
> 0x00071554f4a8, a
> org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator),
>which is held by "Tapestry PeriodicExecutor"
> "Tapestry PeriodicExecutor":
>waiting for ownable synchronizer 0x000716130940, (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync),
>which is held by "main"
>
>
> "main":
> at
>
> org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator.obtainObjectFromCreator(JustInTimeObjectCreator.
Deadlock in IOC (ConcurrentBarrier vs JustInTimeObjectCreator)
Hi everyone,
we recently found a strange deadlock problem; first seemed to be related
to switching from 5.5.0-beta-1 to 5.5.0, at least
in the full application it was easy to reproduce with the latter but (in
a few manual tests) not with the beta.
after trying to reduce it to a minimal test case… it can be triggered
with either (and 5.4.x); maybe in the "real" code the calls
take long enough to avoid the data race or at least make it unlikely.
on to the questions:
* has anyone seen something like this before? closest bug i can find is:
https://issues.apache.org/jira/browse/TAPESTRY-2561
* is this likely related to registry startup? kinda afraid of same
situation during normal operations, though once most/all services
are realized everything should be fine
thanks for reading & any hints you can offer
Regards,
Oliver
it appears all of the following is required:
* a builder method for a simple class (not a service); with some kind of
call to IOC (inject anything)
public static SomeClass build(@Inject @Symbol("some.symbol") String
uri) {
return new SomeClass();
}
* this class is a dependency for a shared service:
public class SharedImpl implements Shared {
public SharedImpl(SomeClass iDoNothing) {
}
* two services marked as eager-load; both require the shared service
public static void bind(ServiceBinder binder) {
binder.bind(JobAdder.class, JobAdderImpl.class).eagerLoad();
binder.bind(Other.class, OtherImpl.class).eagerLoad();
binder.bind(Shared.class, SharedImpl.class);
}
* JobAdder c-tor adds Runnable(s) to PeriodicExecutor
public JobAdderImpl(List parts, PeriodicExecutor exec) {
LOG.info("Blocked here?");
for (RunnableJobData p : parts) {
exec.addJob(new ImmediateStartIntervalSchedule(1000 * 60),
p.name, p.run);
}
}
* the Runnable and OtherImpl (c-tor) call the shared service (instances
are realized)
@Contribute(JobAdder.class)
public static void contributeJobParts(OrderedConfiguration conf,
Shared something) {
conf.add("abc", new RunnableJobData("abc", () -> {
LOG.info("starting job");
something.doFoo();
public class OtherImpl implements Other {
public OtherImpl(Shared xx) {
xx.doFoo();
* the jobs start immediately (no initial delay)
public class ImmediateStartIntervalSchedule extends IntervalSchedule {
public ImmediateStartIntervalSchedule(final long interval) {
super(interval);
}
@Override
public long firstExecution() {
return System.currentTimeMillis();
}
probably the easiest fix (for us) is to avoid the immediate execution of
periodic jobs while "RegistryImpl.performRegistryStartup"
is still running on the main thread; e.g. adding the jobs from a
@Startup method seems to work ok
maybe PeriodicExecutorImpl::start should be called from @Startup instead
of @PostInjection (assuming startup methods are called after the
registry is done, while @PostInjection is called earlier?)
in the trace below both threads "hold" a R-lock, one also has (upgraded
to) W, the second blocks on W … that seems wrong
https://github.com/apache/tapestry-5/blob/master/tapestry-ioc/src/main/java/org/apache/tapestry5/ioc/internal/util/ConcurrentBarrier.java#L54
maybe reentrancy; but i'm not sure about the "upgrade R to W" logic
here is the test source: https://easyupload.io/xzy6j1
Found one Java-level deadlock:
=
"main":
waiting to lock monitor 0x7f7f38008b80 (object
0x00071554f4a8, a
org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator),
which is held by "Tapestry PeriodicExecutor"
"Tapestry PeriodicExecutor":
waiting for ownable synchronizer 0x000716130940, (a
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync),
which is held by "main"
"main":
at
org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator.obtainObjectFromCreator(JustInTimeObjectCreator.java:62)
- waiting to lock <0x00071554f4a8> (a
org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator)
at
org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator.createObject(JustInTimeObjectCreator.java:55)
at $SymbolSource_c9319bed00c.delegate(Unknown Source)
at $SymbolSource_c9319bed00c.valueForSymbol(Unknown Source)
at
org.apache.tapestry5.ioc.internal.services.SymbolObjectProvider.provide(SymbolObjectProvider.java:50)
…
at
org.apache.tapestry5.ioc.internal.ModuleImpl$1.invoke(ModuleImpl.java:198)
at
org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withWrite(ConcurrentBarrier.java:139)
at
org.apache.tapestry5.ioc.internal.ModuleImpl$2.invoke(ModuleImpl.java:215)
at
org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.w
Re: IoC Question
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. One important consideration here is that the same instance is also shared between threads, so in a multi-threading program (which include any web applications) appropriate precautions must be done to prevent race conditions. You can change default scope of the service to be per-thread, (see @Scope annotation), in this case each thread will get a separate instance of the service. On Thu, Oct 5, 2017 at 9:24 PM, Tyler Wilcock wrote: > 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 > EventTracker service and records a bunch of events. > > If I @Inject the EventTracker service into yet another class, can I read > those events that the previous class added? Or will it be an empty slate? > Generally, my question is this: do services save their state in between > injections in different classes? >
Re: IoC Question
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, Tyler Wilcock wrote: > 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 > EventTracker service and records a bunch of events. > > If I @Inject the EventTracker service into yet another class, can I read > those events that the previous class added? Or will it be an empty slate? > Generally, my question is this: do services save their state in between > injections in different classes? > -- Dmitry Gusev AnjLab Team http://anjlab.com
IoC Question
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 EventTracker service and records a bunch of events. If I @Inject the EventTracker service into yet another class, can I read those events that the previous class added? Or will it be an empty slate? Generally, my question is this: do services save their state in between injections in different classes?
Re: Integrating Tapstry IOC only
On Fri, 22 Apr 2016 04:27:26 -0300, Adam X wrote: Why? Just curious. :) Well, that brings me to my problem. What I'm really after is Tapestry's ordered configuration and its chain builder service, so I thought I may as well use IOC since I don't think I can split them. You mean just use distributed configuration and chain builder services? Or let me ask my question differently. Is Tapestry registry, chain builder and ordered configuration in all in the core module? If you consider "core module" to be the IoC whole part (the tapestry-ioc JAR), then yes. And if so, can I just bring in the core module to use it? Yes if the answer above is yes. So in short, after reading: https://tapestry.apache.org/chainbuilder-service.html sounds like it's exactly what I need. If I bring in only tapestry core jar, will I get this? And if I need Tapestry IOC as well, I would happily replace my CDI with IOC. I think you got it backwards, and I agree the naming is confusing: tapestry-core is the Web framework. tapestry-ioc is the IoC and dependency injection framework. For the scenario you described in this thread, you only need tapestry-ioc. tapestry-core by itself depends on tapestry-ioc. Registry, services, dependency injection, distributed configuration, chain builders, etc are all in tapestry-ioc. You don't need tapestry-core at all. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Integrating Tapstry IOC only
Le 21/04/2016 09:18, Adam X a écrit : Hi I have a rest project (no gui) with CDI backed by Weld. I would like to switch to Tapestry IOC instead. Are there any good tutorials that cover this? Adam http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/OT-T5-IoC-in-Fantom-td5722767.html - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Integrating Tapstry IOC only
"Actually, I thought it would be a good joke to mix Wicket and Tapestry and make some die-hard-Wicket user use Tapestry to fill the IOC gap - instead of Spring and Guice.” Funniest thing I’ve read in awhile. Thanks for the laugh. Robert > On Apr 22, 2016, at 4:35 AM, Christian Riedel wrote: > > You would only need Tapestry IoC for the builders. > Many moons ago I replaced Spring with Tapestry IoC in a Wicket project: > https://github.com/criedel/WicketTap5IOC > I bet you can find the appropriate hooks in your project to do something > similar! APIs have changed since 5.2 though. > With what framework would you integrate Tapestry? > >> Am 22.04.2016 um 09:27 schrieb Adam X : >> >>> Why? Just curious. :) >> >> Well, that brings me to my problem. What I'm really after is >> Tapestry's ordered configuration and its chain builder service, so I >> thought I may as well use IOC since I don't think I can split them. Or >> let me ask my question differently. Is Tapestry registry, chain >> builder and ordered configuration in all in the core module? And if >> so, can I just bring in the core module to use it? >> >> My use case is a set of distributed plugins and chain of >> responsibility executing them within the engine of my project. I tried >> apache commons chain but it lacks several features that Tapestry's >> ordered list of chain commands. >> >> So in short, after reading: >> https://tapestry.apache.org/chainbuilder-service.html sounds like it's >> exactly what I need. If I bring in only tapestry core jar, will I get >> this? And if I need Tapestry IOC as well, I would happily replace my >> CDI with IOC. >> >> Adam >> >> On Thu, Apr 21, 2016 at 7:20 PM, Cezary Biernacki >> wrote: >>> I have used Tapestry-IOC in many non-gui tools including REST applications >>> based on Dropwizard, and it is very easy to do. Just in some place during >>> process initialisation build a IOC registry, retrieve some starting service >>> and call that service - later all dependencies can be handled by >>> Tapestry-IOC. I am not aware of any tutorials outside Tapestry website, so >>> ask if you need any more specific help. >>> >>> >>> Best regards, >>> Cezary >>> >>> On Thu, Apr 21, 2016 at 5:20 PM, Thiago H de Paula Figueiredo < >>> thiag...@gmail.com> wrote: >>> >>>> On Thu, 21 Apr 2016 04:18:30 -0300, Adam X wrote: >>>> >>>> Hi >>>>> >>>> >>>> Hi! >>>> >>>> I have a rest project (no gui) with CDI backed by Weld. I would like to >>>>> switch to Tapestry IOC instead. >>>>> >>>> >>>> Why? Just curious. :) I haven't used CDI so I cannot compare it to >>>> Tapestry-IoC. >>>> >>>> Are there any good tutorials that cover this? >>>>> >>>> >>>> It's mostly the same. Just the way you start the Registry is different. >>>> If http://tapestry.apache.org/starting-the-ioc-registry.html isn't >>>> enough, please let us know. >>>> >>>> -- >>>> Thiago H. de Paula Figueiredo >>>> Tapestry, Java and Hibernate consultant and developer >>>> http://machina.com.br >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org >
Re: Integrating Tapstry IOC only
You would only need Tapestry IoC for the builders. Many moons ago I replaced Spring with Tapestry IoC in a Wicket project: https://github.com/criedel/WicketTap5IOC I bet you can find the appropriate hooks in your project to do something similar! APIs have changed since 5.2 though. With what framework would you integrate Tapestry? > Am 22.04.2016 um 09:27 schrieb Adam X : > >> Why? Just curious. :) > > Well, that brings me to my problem. What I'm really after is > Tapestry's ordered configuration and its chain builder service, so I > thought I may as well use IOC since I don't think I can split them. Or > let me ask my question differently. Is Tapestry registry, chain > builder and ordered configuration in all in the core module? And if > so, can I just bring in the core module to use it? > > My use case is a set of distributed plugins and chain of > responsibility executing them within the engine of my project. I tried > apache commons chain but it lacks several features that Tapestry's > ordered list of chain commands. > > So in short, after reading: > https://tapestry.apache.org/chainbuilder-service.html sounds like it's > exactly what I need. If I bring in only tapestry core jar, will I get > this? And if I need Tapestry IOC as well, I would happily replace my > CDI with IOC. > > Adam > > On Thu, Apr 21, 2016 at 7:20 PM, Cezary Biernacki wrote: >> I have used Tapestry-IOC in many non-gui tools including REST applications >> based on Dropwizard, and it is very easy to do. Just in some place during >> process initialisation build a IOC registry, retrieve some starting service >> and call that service - later all dependencies can be handled by >> Tapestry-IOC. I am not aware of any tutorials outside Tapestry website, so >> ask if you need any more specific help. >> >> >> Best regards, >> Cezary >> >> On Thu, Apr 21, 2016 at 5:20 PM, Thiago H de Paula Figueiredo < >> thiag...@gmail.com> wrote: >> >>> On Thu, 21 Apr 2016 04:18:30 -0300, Adam X wrote: >>> >>> Hi >>>> >>> >>> Hi! >>> >>> I have a rest project (no gui) with CDI backed by Weld. I would like to >>>> switch to Tapestry IOC instead. >>>> >>> >>> Why? Just curious. :) I haven't used CDI so I cannot compare it to >>> Tapestry-IoC. >>> >>> Are there any good tutorials that cover this? >>>> >>> >>> It's mostly the same. Just the way you start the Registry is different. >>> If http://tapestry.apache.org/starting-the-ioc-registry.html isn't >>> enough, please let us know. >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> Tapestry, Java and Hibernate consultant and developer >>> http://machina.com.br >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Integrating Tapstry IOC only
> Why? Just curious. :) Well, that brings me to my problem. What I'm really after is Tapestry's ordered configuration and its chain builder service, so I thought I may as well use IOC since I don't think I can split them. Or let me ask my question differently. Is Tapestry registry, chain builder and ordered configuration in all in the core module? And if so, can I just bring in the core module to use it? My use case is a set of distributed plugins and chain of responsibility executing them within the engine of my project. I tried apache commons chain but it lacks several features that Tapestry's ordered list of chain commands. So in short, after reading: https://tapestry.apache.org/chainbuilder-service.html sounds like it's exactly what I need. If I bring in only tapestry core jar, will I get this? And if I need Tapestry IOC as well, I would happily replace my CDI with IOC. Adam On Thu, Apr 21, 2016 at 7:20 PM, Cezary Biernacki wrote: > I have used Tapestry-IOC in many non-gui tools including REST applications > based on Dropwizard, and it is very easy to do. Just in some place during > process initialisation build a IOC registry, retrieve some starting service > and call that service - later all dependencies can be handled by > Tapestry-IOC. I am not aware of any tutorials outside Tapestry website, so > ask if you need any more specific help. > > > Best regards, > Cezary > > On Thu, Apr 21, 2016 at 5:20 PM, Thiago H de Paula Figueiredo < > thiag...@gmail.com> wrote: > >> On Thu, 21 Apr 2016 04:18:30 -0300, Adam X wrote: >> >> Hi >>> >> >> Hi! >> >> I have a rest project (no gui) with CDI backed by Weld. I would like to >>> switch to Tapestry IOC instead. >>> >> >> Why? Just curious. :) I haven't used CDI so I cannot compare it to >> Tapestry-IoC. >> >> Are there any good tutorials that cover this? >>> >> >> It's mostly the same. Just the way you start the Registry is different. >> If http://tapestry.apache.org/starting-the-ioc-registry.html isn't >> enough, please let us know. >> >> -- >> Thiago H. de Paula Figueiredo >> Tapestry, Java and Hibernate consultant and developer >> http://machina.com.br >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Integrating Tapstry IOC only
I have used Tapestry-IOC in many non-gui tools including REST applications based on Dropwizard, and it is very easy to do. Just in some place during process initialisation build a IOC registry, retrieve some starting service and call that service - later all dependencies can be handled by Tapestry-IOC. I am not aware of any tutorials outside Tapestry website, so ask if you need any more specific help. Best regards, Cezary On Thu, Apr 21, 2016 at 5:20 PM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Thu, 21 Apr 2016 04:18:30 -0300, Adam X wrote: > > Hi >> > > Hi! > > I have a rest project (no gui) with CDI backed by Weld. I would like to >> switch to Tapestry IOC instead. >> > > Why? Just curious. :) I haven't used CDI so I cannot compare it to > Tapestry-IoC. > > Are there any good tutorials that cover this? >> > > It's mostly the same. Just the way you start the Registry is different. > If http://tapestry.apache.org/starting-the-ioc-registry.html isn't > enough, please let us know. > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Integrating Tapstry IOC only
On Thu, 21 Apr 2016 04:18:30 -0300, Adam X wrote: Hi Hi! I have a rest project (no gui) with CDI backed by Weld. I would like to switch to Tapestry IOC instead. Why? Just curious. :) I haven't used CDI so I cannot compare it to Tapestry-IoC. Are there any good tutorials that cover this? It's mostly the same. Just the way you start the Registry is different. If http://tapestry.apache.org/starting-the-ioc-registry.html isn't enough, please let us know. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Integrating Tapstry IOC only
Hi I have a rest project (no gui) with CDI backed by Weld. I would like to switch to Tapestry IOC instead. Are there any good tutorials that cover this? Adam
Re: Standalone IOC and service overrides
I encountered the same problem with Tapestry IOC 5.4beta.
registry.getService() doesn't respect service overrides. Is this a designed
feature or a bug?
2013-12-13 2:20 GMT+08:00 Adriaan Joubert :
> Hi,
>
> we love the IOC and are using it in our standalone Java applications as
> well as our web applications. I do however have a problem with overriding
> services. When using the suggestions from the cookbook (
> http://tapestry.apache.org/ioc-cookbook-overriding-ioc-services.html) to
> override a service, I find that the the service is not overridden using the
> getService method on the registry. I've been through the IOC code and I
> could see that the ServiceOverride service is called from the
> MasterObjectProvider but not from elsewhere. Based on that I tried to use
> the getObject() method on the registry, and that does indeed give me the
> overridden service. I found this behaviour rather unexpected, so I assume
> I'm missing something.
>
> We use getService in a lot of places, and it would be quite a change to
> have to use getObject everywhere instead. As we have markers on our
> services, the getService interface is also easier to use.
>
> So my question is: why the difference between getService and getObject? And
> which one should we be using?
>
> Please see below a junit test that demonstrates this behaviour. I'd really
> appreciate any enlightenment!
>
> Cheers,
>
> Adriaan
>
>
> import static org.junit.Assert.assertEquals;
>
> import org.apache.tapestry5.ioc.MappedConfiguration;
> import org.apache.tapestry5.ioc.Registry;
> import org.apache.tapestry5.ioc.RegistryBuilder;
> import org.apache.tapestry5.ioc.ServiceBinder;
> import org.apache.tapestry5.ioc.annotations.Contribute;
> import org.apache.tapestry5.ioc.annotations.SubModule;
> import org.apache.tapestry5.ioc.internal.NullAnnotationProvider;
> import org.apache.tapestry5.ioc.services.ServiceOverride;
> import org.junit.Test;
>
> public class IocTest {
>
> public interface Simple {
> String getString();
> }
>
> public static class SimpleImpl implements Simple {
> @Override
> public String getString() {
> return "foo";
> }
> }
>
> public static class SimpleOverrideImpl implements Simple {
> @Override
> public String getString() {
> return "bar";
> }
> }
>
> public static class DefaultAppModule {
> public static void bind(ServiceBinder binder) {
> binder.bind(Simple.class, SimpleImpl.class);
> }
> }
>
> @SubModule(DefaultAppModule.class)
> public static class OverrideAppModule {
> @Contribute(ServiceOverride.class)
> public static void testOverrides(
> MappedConfiguration, Object> configuration) {
> configuration.addInstance(Simple.class,
> SimpleOverrideImpl.class);
> }
> }
>
> @Test
> public void testWithoutOverride() {
> RegistryBuilder builder = new RegistryBuilder();
> builder.add(DefaultAppModule.class);
> Registry registry = builder.build();
> registry.performRegistryStartup();
> Simple simple = registry.getService(Simple.class);
> assertEquals("foo", simple.getString());
> registry.cleanupThread();
> registry.shutdown();
> }
>
> @Test
> public void testWithOverride() {
> RegistryBuilder builder = new RegistryBuilder();
> builder.add(OverrideAppModule.class);
> Registry registry = builder.build();
> registry.performRegistryStartup();
> Simple simple = registry.getService(Simple.class);
> // !FAILS!
> assertEquals("bar", simple.getString());
> registry.cleanupThread();
> registry.shutdown();
> }
>
> @Test
> public void testWithOverrideAndObjectProvider() {
> RegistryBuilder builder = new RegistryBuilder();
> builder.add(OverrideAppModule.class);
> Registry registry = builder.build();
> registry.performRegistryStartup();
> Simple simple = registry.getObject(Simple.class,
> new NullAnnotationProvider());
> // SUCCEEDS
> assertEquals("bar", simple.getString());
> registry.cleanupThread();
> registry.shutdown();
> }
>
> }
>
Re: Custom ValueEncoder & IOC
On Mon, 14 Sep 2015 10:41:49 -0300, Chris Poulsen wrote: Can't you could just bind it in your app module? Yep! Or also contribute it to the ValueEncoderSource service, so it's automatically picked up by Select and other components. As in any other IoC container, in order to have dependencies injected, you must make your object/class a service/bean which is instantiated by the IoC container. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Custom ValueEncoder & IOC
Can't you could just bind it in your app module?
--
Chris
On Mon, Sep 14, 2015 at 3:35 PM, Damon Childs wrote:
> How do i get a custom ValueEncoder under control of IOC?
>
> I have a ValueEncoder that translates a id to a Object from a db.
>
> public class PropertyTypeEncoder implements
> ValueEncoder {
>
> @Inject
> private Session session;
>
> public PropertyTypeEncoder(Session session) {
> this.session = session;
> }
>
> public String toClient(LookupPropertyType value) {
> return String.valueOf(value.getId());
> }
>
> public LookupPropertyType toValue(String id) {
> Criteria criteria =
> session.createCriteria(LookupPropertyType.class);
> criteria.add(Restrictions.eq("id", Long.parseLong(id)));
> LookupPropertyType type =
> (LookupPropertyType)criteria.uniqueResult();
> return type;
> }
> }
>
> To get it created of the web form I have:
> @Property
> private final PropertyTypeEncoder propertyTypeEncoder = new
> PropertyTypeEncoder(this.session);
>
> Im passing the Hibernate session via the constructer since this would not
> be under the IOC’s control.
>
> Is there a way to create this using the IOC so the inject works?
>
> Thanks,
> Damon
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Custom ValueEncoder & IOC
How do i get a custom ValueEncoder under control of IOC?
I have a ValueEncoder that translates a id to a Object from a db.
public class PropertyTypeEncoder implements ValueEncoder {
@Inject
private Session session;
public PropertyTypeEncoder(Session session) {
this.session = session;
}
public String toClient(LookupPropertyType value) {
return String.valueOf(value.getId());
}
public LookupPropertyType toValue(String id) {
Criteria criteria = session.createCriteria(LookupPropertyType.class);
criteria.add(Restrictions.eq("id", Long.parseLong(id)));
LookupPropertyType type = (LookupPropertyType)criteria.uniqueResult();
return type;
}
}
To get it created of the web form I have:
@Property
private final PropertyTypeEncoder propertyTypeEncoder = new
PropertyTypeEncoder(this.session);
Im passing the Hibernate session via the constructer since this would not be
under the IOC’s control.
Is there a way to create this using the IOC so the inject works?
Thanks,
Damon
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
AW: Tapestry IoC - Two Implementations of the same Service class - Symbol Providers
Hello,
I can answer this myself, because I was just too stupid to parse that I used
the same object reference twice when adding to the SymbolSource configuration.
Which in turn led to my page not recognizing some symbols, because of course
they weren't there.
Regards,
Daniel P.
-Ursprüngliche Nachricht-
Von: Poggenpohl, Daniel [mailto:daniel.poggenp...@isst.fraunhofer.de]
Gesendet: Donnerstag, 3. September 2015 21:01
An: users@tapestry.apache.org
Betreff: Tapestry IoC - Two Implementations of the same Service class - Symbol
Providers
Hello everyone,
I have a FileSymbolProvider. It looks for a file in the webapp classpath and
reads the properties from the file.
I have defined two services based on the FileSymbolProvider, FileXProvider and
FileYProvider.
One of them is configured to generate default values for properties with no
values.
I have contributed both services to the SymbolSource configuration. But looking
deep into Tapestry code, the providers list inside the SymbolSource contains
not references to both SymbolProviders, but two references to the same
SymbolProvider.
What am I doing wrong?
Code reference:
@ServiceId(value = "FileXProvider")
public FileSymbolProvider buildFileXProvider(Map
contributions, Logger logger)
{
return new FileSymbolProvider(contributions, logger, FILE_X_FILENAME,
true);
}
@ServiceId(value = "FileYProvider")
public FileSymbolProvider buildFileYProvider(Map contributions,
Logger logger) {
return new FileSymbolProvider(contributions, logger, FILE_Y_FILENAME, true);
}
public static void contributeFileXProvider(MappedConfiguration
configuration) {
configuration.add(FileSymbolProvider.GENERATE_DEFAULTS_KEY, true);
configuration.add(FileSymbolProvider.DEFAULT_VALUE_KEY, "UNKNOWN"); }
public static void contributeSymbolSource(
OrderedConfiguration configuration,
@InjectService("FileXProvider") SymbolProvider fileXProvider,
@InjectService("FileYProvider") SymbolProvider fileYProvider) {
configuration.add(FILE_X_FILENAME, fileXProvider,
"after:SystemProperties", "before:ApplicationDefaults");
configuration.add(FILE_Y_FILENAME, fileYProvider, "after:SystemProperties",
"before:ApplicationDefaults");
}
Regards,
Daniel
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Tapestry IoC - Two Implementations of the same Service class - Symbol Providers
Hello everyone,
I have a FileSymbolProvider. It looks for a file in the webapp classpath and
reads the properties from the file.
I have defined two services based on the FileSymbolProvider, FileXProvider and
FileYProvider.
One of them is configured to generate default values for properties with no
values.
I have contributed both services to the SymbolSource configuration. But looking
deep into Tapestry code, the providers list inside the SymbolSource contains
not references to both SymbolProviders, but two references to the same
SymbolProvider.
What am I doing wrong?
Code reference:
@ServiceId(value = "FileXProvider")
public FileSymbolProvider buildFileXProvider(Map
contributions, Logger logger)
{
return new FileSymbolProvider(contributions, logger, FILE_X_FILENAME,
true);
}
@ServiceId(value = "FileYProvider")
public FileSymbolProvider buildFileYProvider(Map contributions,
Logger logger)
{
return new FileSymbolProvider(contributions, logger, FILE_Y_FILENAME, true);
}
public static void contributeFileXProvider(MappedConfiguration
configuration) {
configuration.add(FileSymbolProvider.GENERATE_DEFAULTS_KEY, true);
configuration.add(FileSymbolProvider.DEFAULT_VALUE_KEY, "UNKNOWN");
}
public static void contributeSymbolSource(
OrderedConfiguration configuration,
@InjectService("FileXProvider") SymbolProvider fileXProvider,
@InjectService("FileYProvider") SymbolProvider fileYProvider) {
configuration.add(FILE_X_FILENAME, fileXProvider,
"after:SystemProperties", "before:ApplicationDefaults");
configuration.add(FILE_Y_FILENAME, fileYProvider, "after:SystemProperties",
"before:ApplicationDefaults");
}
Regards,
Daniel
Re: IoC Service, call a method after instantiation/realization
Thanks guys, I'll play around with @Startup in the next day or so.
Unfortunately my workflow at the moment is tapestry/hibernate at prototype
stage then moves to EJB with JPA when things get serious!
On Sun, 12 Apr 2015 20:36:51 +1000, Kalle Korhonen
wrote:
Also, if you are using Hibernate or JPA, you should definitely check out
http://tynamo.org/tapestry-hibernate-seedentity+guide for the entity
seeding needs.
Kalle
On Sun, Apr 12, 2015 at 3:26 AM, Charlouze wrote:
Hey!
The tapestry @startup annotation is to be used in modules. The annotated
method will be called upon application startup after the registry
setup. If
you need those methods to be called in a specific order, you should
contribute to RegistryStartup.
I hope it'll help you.
Le dim 12 avr. 2015 06:30, Chris Mylonas a écrit :
> Hi Tapestry Users,
>
> Tapestry development is on the horizon again for me and I'm just
making
> some tweaks to an app that I'm trying to load in another CMS's iframe!
>
>
> After service class instantiation, I'd like to call a method so it
does
> something (e.g. create an admin user if none exist)
>
> //annotate with tapestry service initlised post runner
> @PostInjection or @Startup
> private void createAdminUser(){
> SubnetsUser u = new SubnetsUser();
> u.setRole(Role.ADMIN);
> u.setEmail("ch...@opencsta.org");
> u.setPassword("subnets");
> save(u);
> }
>
> Is this the way? Doesn't seem to be working at the moment for me
>
> Thanks
> Chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Using Opera's mail client: http://www.opera.com/mail/
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC Service, call a method after instantiation/realization
Also, if you are using Hibernate or JPA, you should definitely check out
http://tynamo.org/tapestry-hibernate-seedentity+guide for the entity
seeding needs.
Kalle
On Sun, Apr 12, 2015 at 3:26 AM, Charlouze wrote:
> Hey!
>
> The tapestry @startup annotation is to be used in modules. The annotated
> method will be called upon application startup after the registry setup. If
> you need those methods to be called in a specific order, you should
> contribute to RegistryStartup.
>
> I hope it'll help you.
>
> Le dim 12 avr. 2015 06:30, Chris Mylonas a écrit :
>
> > Hi Tapestry Users,
> >
> > Tapestry development is on the horizon again for me and I'm just making
> > some tweaks to an app that I'm trying to load in another CMS's iframe!
> >
> >
> > After service class instantiation, I'd like to call a method so it does
> > something (e.g. create an admin user if none exist)
> >
> > //annotate with tapestry service initlised post runner
> > @PostInjection or @Startup
> > private void createAdminUser(){
> > SubnetsUser u = new SubnetsUser();
> > u.setRole(Role.ADMIN);
> > u.setEmail("ch...@opencsta.org");
> > u.setPassword("subnets");
> > save(u);
> > }
> >
> > Is this the way? Doesn't seem to be working at the moment for me
> >
> > Thanks
> > Chris
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
> >
>
Re: IoC Service, call a method after instantiation/realization
Hey!
The tapestry @startup annotation is to be used in modules. The annotated
method will be called upon application startup after the registry setup. If
you need those methods to be called in a specific order, you should
contribute to RegistryStartup.
I hope it'll help you.
Le dim 12 avr. 2015 06:30, Chris Mylonas a écrit :
> Hi Tapestry Users,
>
> Tapestry development is on the horizon again for me and I'm just making
> some tweaks to an app that I'm trying to load in another CMS's iframe!
>
>
> After service class instantiation, I'd like to call a method so it does
> something (e.g. create an admin user if none exist)
>
> //annotate with tapestry service initlised post runner
> @PostInjection or @Startup
> private void createAdminUser(){
> SubnetsUser u = new SubnetsUser();
> u.setRole(Role.ADMIN);
> u.setEmail("ch...@opencsta.org");
> u.setPassword("subnets");
> save(u);
> }
>
> Is this the way? Doesn't seem to be working at the moment for me
>
> Thanks
> Chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
IoC Service, call a method after instantiation/realization
Hi Tapestry Users,
Tapestry development is on the horizon again for me and I'm just making
some tweaks to an app that I'm trying to load in another CMS's iframe!
After service class instantiation, I'd like to call a method so it does
something (e.g. create an admin user if none exist)
//annotate with tapestry service initlised post runner
@PostInjection or @Startup
private void createAdminUser(){
SubnetsUser u = new SubnetsUser();
u.setRole(Role.ADMIN);
u.setEmail("ch...@opencsta.org");
u.setPassword("subnets");
save(u);
}
Is this the way? Doesn't seem to be working at the moment for me
Thanks
Chris
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Adding IOC services from pico
Thanks Thiago! I finally got it working so now I have access to my pico services from Tapestry code. Which is great! /Gunnar 2014-11-18 13:55 GMT+01:00 Thiago H de Paula Figueiredo : > On Tue, 18 Nov 2014 10:39:52 -0200, Lance Java > wrote: > > This might help >> >> https://github.com/apache/tapestry-5/search?utf8=%E2%9C%93&q=Mapmoduledef >> > > Have you tried contributing an ObjectProvider to the MasterObjectProvider > service? This won't allow your Pico-provided objects to be Tapestry-IoC > services, but you'll be able to @Inject them. > > > On 18 Nov 2014 11:00, "Gunnar Eketrapp" >> wrote: >> >> Hi! >>> >>> >>> I would like to add service from our own ioc container (pico based) so >>> that they may used in my tapestry projects. >>> >>> I.e. I have an ioc container used within none Tapestry projects. >>> >>> Now I would like to be able to use those services from within my Tapestry >>> pages components and services. >>> >>> >>> I didn't find any example on how to do it for pico but found this for >>> guice >>> http://tawus.wordpress.com/2011/04/22/tapestry-magic-4- >>> integrating-guice/ >>> >>> I tried to follow that one and adopt it for our container but have not >>> been lucky yet! >>> >>> I have created 4 classes (Our own IOC container is called >>> ApplicationContainer) >>> >>> TapestryApplicationContainerFilter.java >>> ApplicationContainerModuleDef.java >>> ApplicationContainerObjectProvider.java >>> ApplicationContainerServiceDef.java >>> >>> But I cant figure out how the ServiceDef and ObjectProvider should be >>> implemented. >>> >>> Thanks in advance! >>> /Gunnar Eketrapp >>> >>> >>> >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- [Hem: 08-715 59 57, Mobil: 0708-52 62 90] Allévägen 2A, 132 42 Saltsjö-Boo
Re: Adding IOC services from pico
On Tue, 18 Nov 2014 10:39:52 -0200, Lance Java wrote: This might help https://github.com/apache/tapestry-5/search?utf8=%E2%9C%93&q=Mapmoduledef Have you tried contributing an ObjectProvider to the MasterObjectProvider service? This won't allow your Pico-provided objects to be Tapestry-IoC services, but you'll be able to @Inject them. On 18 Nov 2014 11:00, "Gunnar Eketrapp" wrote: Hi! I would like to add service from our own ioc container (pico based) so that they may used in my tapestry projects. I.e. I have an ioc container used within none Tapestry projects. Now I would like to be able to use those services from within my Tapestry pages components and services. I didn't find any example on how to do it for pico but found this for guice http://tawus.wordpress.com/2011/04/22/tapestry-magic-4-integrating-guice/ I tried to follow that one and adopt it for our container but have not been lucky yet! I have created 4 classes (Our own IOC container is called ApplicationContainer) TapestryApplicationContainerFilter.java ApplicationContainerModuleDef.java ApplicationContainerObjectProvider.java ApplicationContainerServiceDef.java But I cant figure out how the ServiceDef and ObjectProvider should be implemented. Thanks in advance! /Gunnar Eketrapp - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Adding IOC services from pico
This might help https://github.com/apache/tapestry-5/search?utf8=%E2%9C%93&q=Mapmoduledef On 18 Nov 2014 11:00, "Gunnar Eketrapp" wrote: > Hi! > > > I would like to add service from our own ioc container (pico based) so > that they may used in my tapestry projects. > > I.e. I have an ioc container used within none Tapestry projects. > > Now I would like to be able to use those services from within my Tapestry > pages components and services. > > > I didn't find any example on how to do it for pico but found this for > guice > http://tawus.wordpress.com/2011/04/22/tapestry-magic-4-integrating-guice/ > > I tried to follow that one and adopt it for our container but have not > been lucky yet! > > I have created 4 classes (Our own IOC container is called > ApplicationContainer) > > TapestryApplicationContainerFilter.java > ApplicationContainerModuleDef.java > ApplicationContainerObjectProvider.java > ApplicationContainerServiceDef.java > > But I cant figure out how the ServiceDef and ObjectProvider should be > implemented. > > Thanks in advance! > /Gunnar Eketrapp > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org >
Re: Adding IOC services from pico
I can't see the atcachements in Nabble .. can you see them? I.e. I attached 4 source code files.
Adding IOC services from pico
Hi! I would like to add service from our own ioc container (pico based) so that they may used in my tapestry projects. I.e. I have an ioc container used within none Tapestry projects. Now I would like to be able to use those services from within my Tapestry pages components and services. I didn't find any example on how to do it for pico but found this for guice http://tawus.wordpress.com/2011/04/22/tapestry-magic-4-integrating-guice/ I tried to follow that one and adopt it for our container but have not been lucky yet! I have created 4 classes (Our own IOC container is called ApplicationContainer) TapestryApplicationContainerFilter.java ApplicationContainerModuleDef.java ApplicationContainerObjectProvider.java ApplicationContainerServiceDef.java But I cant figure out how the ServiceDef and ObjectProvider should be implemented. Thanks in advance! /Gunnar Eketrapp - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Distributed configuration of Spring Application context in a non-web Tapestry-ioc project
Thanks. We'll explore that path.
The intention is to get rid of the servlet api dependency. The
approach has been: take something that works, and make as few changes
as possible to get something else that works, then go from there.
Ultimately, we want tapestry-ioc-spring. As a matter of fact, that's
what we are calling the project :-)
On Tue, Oct 21, 2014 at 9:37 PM, Lance Java wrote:
> The easiest way I can think of is to have an ApplicationContextProvider
> service which is defined by your tapestry module.
>
> eg:
> @UsesOrderedConfiguration(String.class)
> public interface ApplicationContextProvider {
> ApplicationContext getApplicationContext();
> }
>
> Then, in your custom SpringModuleDef you'll call
> ServiceBuilderResources.getService(ApplicationContextProvider.class) to get
> an ApplicationContext instance.
>
> You could then have use distributed configuration to define the app context
> files for the OrderedConfiguration.
>
> As I said earlier, I think this highlights a bigger problem that you need
> the servlet api on your classpath for a non-web app. Perhaps
> tapestry-spring needs to be split into tapestry-ioc-spring and
> tapestry-spring.
--
Jonathan Barker
ITStrategic
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Distributed configuration of Spring Application context in a non-web Tapestry-ioc project
The easiest way I can think of is to have an ApplicationContextProvider
service which is defined by your tapestry module.
eg:
@UsesOrderedConfiguration(String.class)
public interface ApplicationContextProvider {
ApplicationContext getApplicationContext();
}
Then, in your custom SpringModuleDef you'll call
ServiceBuilderResources.getService(ApplicationContextProvider.class) to get
an ApplicationContext instance.
You could then have use distributed configuration to define the app context
files for the OrderedConfiguration.
As I said earlier, I think this highlights a bigger problem that you need
the servlet api on your classpath for a non-web app. Perhaps
tapestry-spring needs to be split into tapestry-ioc-spring and
tapestry-spring.
Re: Distributed configuration of Spring Application context in a non-web Tapestry-ioc project
At the moment, there is a dummy servlet context being provided. I suggested keeping the code as close as possible to the original until we had things working. That being said, we have created our own SpringModuleDef in anticipation of additional changes. I'm accustomed to doing distributed contributions for service configurations, but I don't see how to get at a configuration from within the constructObjectCreatorForApplicationContext method. On Tue, Oct 21, 2014 at 12:34 PM, Lance Java wrote: > Considering this is a non-web project, I assume that WebApplicationContext > is not on the classpath. It seems that SpringModuleDef is not suitable for > you since it references ServletContext which I also assume is not on your > classpath. -- Jonathan Barker ITStrategic - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Distributed configuration of Spring Application context in a non-web Tapestry-ioc project
It seems to me that SpringModuleDef needs to be refactored to support non-web projects, possibly by the use of an ApplicationContextProvider or similar service. On 21 Oct 2014 17:34, "Lance Java" wrote: > > Considering this is a non-web project, I assume that WebApplicationContext is not on the classpath. It seems that SpringModuleDef is not suitable for you since it references ServletContext which I also assume is not on your classpath.
Re: Distributed configuration of Spring Application context in a non-web Tapestry-ioc project
Considering this is a non-web project, I assume that WebApplicationContext is not on the classpath. It seems that SpringModuleDef is not suitable for you since it references ServletContext which I also assume is not on your classpath.
Distributed configuration of Spring Application context in a non-web Tapestry-ioc project
Hi all, We have created a stripped-down "tapestry-spring" project to allow us to use Spring from within a Tapestry-ioc based non-web project. One objective is to be able to drop in jars and not only have services and configuration information from Tapestry modules picked up, but also contribute locations of applicationContext files and have them combined as well. This is comparable to specifying multiple files in web.xml for a normal Tapestry-Spring web application. We've hit analysis-paralyisis trying to figure out how to get the list of Strings (ApplicationContext.xml fragment locations) available at the right time. The comparable location for tapestry-spring seems to be in SpringModuleDef in the method: private ObjectCreator constructObjectCreatorForApplicationContext( final ServiceBuilderResources resources, @Primary ApplicationContextCustomizer customizer) at the line: WebApplicationContext context = loader.initWebApplicationContext(servletContext); By the time we hit this line, we need to have the contributions available. Can a configuration built up from distributed contribute methods be accessed/used at this point? How? I've never quite been able to get away from Spring, because I frequently have to deal with multiple databases, and I like their transaction management. In the past few years, we've been using Apache Camel extensively in web applications and non-web integration projects. That's also been easier to achieve in Spring, but the number of Camel processes I have running is going to get more difficult to manage. We've built a tapestry-ioc integration for Camel so we can do distributed contribution of routes, but we're bumping up against this one issue. Regards, Jonathan -- Jonathan Barker ITStrategic - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry-IoC and Runnable/ThreadPoolExecutor
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 Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Tapestry-IoC and Runnable/ThreadPoolExecutor
Hi All Tapestry Ppl, IoC caught my eye when I first touched tapestry some years back and I've been fortunate to have a good dig at tapestry for web development a few times this year again! I'd like to use Tapestry-IoC in my old-pet open source project for controlling older telecommunications equipment, Open CSTA Server. Specifically, 1. Server is multi-threaded, does not run in servlet API. 2. One thread per connected raw TCP client (interface TCPOwnerInterface), potentially adding HTTP/XMMP/SIP client/server implementations 3. One "Link" whether Serial connection or Network connection to equipment (interface CSTA_Link_Interface <- how i learned a bit of generic programming) 1,2,3 all seem within the realm of Tapestry-IoC's uses. aaa) What are the basics in firing it up? Say from a main() method, *unmanaged* i know...i read the IoC overview :) I also used to have a development philosophy that everything should be Runnable so it was easier to throw into an executor thread pool for testing stuff quickly (with equipment responses, not mock testing) and hackily. The project opencsta project source code is ready for a code update and I'd like to start using Tapestry-IoC to learn better ways of doing stuff... I think getting question [aaa] answered will keep me busy finding time for the rest of the month tinkering with it if someone could suggest a quick and easy first step. Thanks for reading, Chris - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Splitting Tapestry IOC out as a separate project
Try Tynamo Resteasy! I think you'll like it. We use it to support a extjs front end we have (served in its raw form (html and js) as part of a Tapestry web application. We jave tapestry pages working right alongside the raw html/js page. Even better is that our rest resources use the same services that our tapestry pages use! On Oct 2, 2014 11:10 AM, "Thiago H de Paula Figueiredo" wrote: > On Thu, 02 Oct 2014 11:38:39 -0300, wrote: > > I expect to use something like Jersey to support a REST API (both >> internal and external) instead of Tapestry pages to handle requests. >> > > Ok! Just giving an suggestion. :) Have you seen > http://tynamo.org/tapestry-resteasy+guide? > > Perhaps I worded my question incorrectly. I’m really wondering if IOC >> will always be tied to Tapestry core in terms of releases, or will it be >> spun off into its own self-contained project with a release cycle >> independent of Tapestry core? >> > > We have no plans of spinning it off nor having a independent release cycle > because, so far, we haven't felt the need for that. Tapestry-IoC is mature > and very flexible, so almost all new features you could think won't need > changes to T-IoC code itself, so they can be implemented in separate > projects. In the last years, the only major changes were live class > reloading for services and copying service implementation class annotations > to its proxies (both at class- and method-level). For example, I've > implemented the support of JCache (JSR 107) annotations as a separate > projects because since the latest betas it didn't need anything > Tapestry-IoC already provides. In addition, nothing prevents us from > generating a new Tapestry release because of a Tapestry-IoC new feature or > improvement. > > Any suggestions on how to improve Tapestry-IoC? We'd love to hear them. :) > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Splitting Tapestry IOC out as a separate project
On Thu, 02 Oct 2014 11:38:39 -0300, wrote: I expect to use something like Jersey to support a REST API (both internal and external) instead of Tapestry pages to handle requests. Ok! Just giving an suggestion. :) Have you seen http://tynamo.org/tapestry-resteasy+guide? Perhaps I worded my question incorrectly. I’m really wondering if IOC will always be tied to Tapestry core in terms of releases, or will it be spun off into its own self-contained project with a release cycle independent of Tapestry core? We have no plans of spinning it off nor having a independent release cycle because, so far, we haven't felt the need for that. Tapestry-IoC is mature and very flexible, so almost all new features you could think won't need changes to T-IoC code itself, so they can be implemented in separate projects. In the last years, the only major changes were live class reloading for services and copying service implementation class annotations to its proxies (both at class- and method-level). For example, I've implemented the support of JCache (JSR 107) annotations as a separate projects because since the latest betas it didn't need anything Tapestry-IoC already provides. In addition, nothing prevents us from generating a new Tapestry release because of a Tapestry-IoC new feature or improvement. Any suggestions on how to improve Tapestry-IoC? We'd love to hear them. :) -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Splitting Tapestry IOC out as a separate project
I expect to use something like Jersey to support a REST API (both internal and external) instead of Tapestry pages to handle requests. Perhaps I worded my question incorrectly. I’m really wondering if IOC will always be tied to Tapestry core in terms of releases, or will it be spun off into its own self-contained project with a release cycle independent of Tapestry core? — Sent from Mailbox On Thu, Oct 2, 2014 at 9:21 AM, Thiago H de Paula Figueiredo wrote: > On Thu, 02 Oct 2014 01:14:27 -0300, raygarsta...@gmail.com > wrote: >> Just curious - are there any plans to carve out the IOC portion of >> Tapestry and release that as a separate project? Since I’m moving >> towards client-side frameworks (such as angular and ember) for future >> projects, I don’t have much need for TML, page, and component-related >> logic. But, I’m quite find of Tapestry IOC. I suspect this approach >> will become more common over time. > Tapestry-IoC is a separate project (as in separate source code tree in SVN > then Git) and JAR since it was born, around 7.5 years ago. See > http://search.maven.org/#search%7Cgav%7C3%7Cg%3A%22org.apache.tapestry%22%20AND%20a%3A%22tapestry-ioc%22. > > What made you think it was a part of tapestry-core (the web framework)? > Even using client-side frameworks, you still need something on the > server-side to receive and respond to requests, so you can still use > Tapestry pages for it, or at least the Tapestry request pipelines. > And yes, Tapestry-IoC is awesome! :D > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Splitting Tapestry IOC out as a separate project
On Thu, 02 Oct 2014 01:14:27 -0300, raygarsta...@gmail.com wrote: Just curious - are there any plans to carve out the IOC portion of Tapestry and release that as a separate project? Since I’m moving towards client-side frameworks (such as angular and ember) for future projects, I don’t have much need for TML, page, and component-related logic. But, I’m quite find of Tapestry IOC. I suspect this approach will become more common over time. Tapestry-IoC is a separate project (as in separate source code tree in SVN then Git) and JAR since it was born, around 7.5 years ago. See http://search.maven.org/#search%7Cgav%7C3%7Cg%3A%22org.apache.tapestry%22%20AND%20a%3A%22tapestry-ioc%22. What made you think it was a part of tapestry-core (the web framework)? Even using client-side frameworks, you still need something on the server-side to receive and respond to requests, so you can still use Tapestry pages for it, or at least the Tapestry request pipelines. And yes, Tapestry-IoC is awesome! :D -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Splitting Tapestry IOC out as a separate project
Tapestry IOC is a separate module and can be used standalone. On 2 Oct 2014 06:38, "raygarsta...@gmail.com" wrote: > Just curious - are there any plans to carve out the IOC portion of > Tapestry and release that as a separate project? Since I’m moving towards > client-side frameworks (such as angular and ember) for future projects, I > don’t have much need for TML, page, and component-related logic. But, I’m > quite find of Tapestry IOC. I suspect this approach will become more > common over time. > > — > Sent from Mailbox
Splitting Tapestry IOC out as a separate project
Just curious - are there any plans to carve out the IOC portion of Tapestry and release that as a separate project? Since I’m moving towards client-side frameworks (such as angular and ember) for future projects, I don’t have much need for TML, page, and component-related logic. But, I’m quite find of Tapestry IOC. I suspect this approach will become more common over time. — Sent from Mailbox
Re: Tapestry ioc/registry startup exception?
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? For my project, I have just settled with using JDK 7, but that isn't necessarily ideal. Thanks, On 2 September 2014 11:37, Lance Java wrote: > 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). - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry ioc/registry startup exception?
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).
Re: Tapestry ioc/registry startup exception?
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 Error building service proxy for service 'RegistryStartup' (at org.apache.tapestry5.ioc.internal.services.RegistryStartup(Logger, List) (at RegistryStartup.java:36) via org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder) (at TapestryIOCModule.java:49)): java.lang.IllegalArgumentException ioc.Registry Operations trace: ioc.Registry [ 1] Creating proxy for service RegistryStartup 2014-09-02 10:58:14.744::WARN: failed app org.apache.tapestry5.ioc.internal.OperationException: Error building service proxy for service 'RegistryStartup' (at org.apache.tapestry5.ioc.internal.services.RegistryStartup(Logger, List) (at RegistryStartup.java:36) via org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder) (at TapestryIOCModule.java:49)): java.lang.IllegalArgumentException at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:121) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:88) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124) at org.apache.tapestry5.ioc.internal.ModuleImpl.create(ModuleImpl.java:332) at org.apache.tapestry5.ioc.internal.ModuleImpl.access$100(ModuleImpl.java:39) at org.apache.tapestry5.ioc.internal.ModuleImpl$1.invoke(ModuleImpl.java:191) at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withWrite(ConcurrentBarrier.java:140) at org.apache.tapestry5.ioc.internal.ModuleImpl$2.invoke(ModuleImpl.java:207) at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85) at org.apache.tapestry5.ioc.internal.ModuleImpl.findOrCreate(ModuleImpl.java:213) at org.apache.tapestry5.ioc.internal.ModuleImpl.getService(ModuleImpl.java:109) at org.apache.tapestry5.ioc.internal.RegistryImpl.getService(RegistryImpl.java:421) at org.apache.tapestry5.ioc.internal.RegistryImpl.performRegistryStartup(RegistryImpl.java:325) at org.apache.tapestry5.ioc.internal.RegistryWrapper.performRegistryStartup(RegistryWrapper.java:80) at org.apache.tapestry5.TapestryFilter.init(TapestryFilter.java:118) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:653) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:222) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleMod
Tapestry ioc/registry startup exception?
Hi, Any pointers on why my app won't start pls? John ioc.Registry Error building service proxy for service 'RegistryStartup' (at org.apache.tapestry5.ioc.internal.services.RegistryStartup(Logger, List) (at RegistryStartup.java:36) via org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder) (at TapestryIOCModule.java:49)): java.lang.IllegalArgumentException ioc.Registry Operations trace: ioc.Registry [ 1] Creating proxy for service RegistryStartup 2014-09-02 10:58:14.744::WARN: failed app org.apache.tapestry5.ioc.internal.OperationException: Error building service proxy for service 'RegistryStartup' (at org.apache.tapestry5.ioc.internal.services.RegistryStartup(Logger, List) (at RegistryStartup.java:36) via org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder) (at TapestryIOCModule.java:49)): java.lang.IllegalArgumentException at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:121) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:88) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124) at org.apache.tapestry5.ioc.internal.ModuleImpl.create(ModuleImpl.java:332) at org.apache.tapestry5.ioc.internal.ModuleImpl.access$100(ModuleImpl.java:39) at org.apache.tapestry5.ioc.internal.ModuleImpl$1.invoke(ModuleImpl.java:191) at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withWrite(ConcurrentBarrier.java:140) at org.apache.tapestry5.ioc.internal.ModuleImpl$2.invoke(ModuleImpl.java:207) at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85) at org.apache.tapestry5.ioc.internal.ModuleImpl.findOrCreate(ModuleImpl.java:213) at org.apache.tapestry5.ioc.internal.ModuleImpl.getService(ModuleImpl.java:109) at org.apache.tapestry5.ioc.internal.RegistryImpl.getService(RegistryImpl.java:421) at org.apache.tapestry5.ioc.internal.RegistryImpl.performRegistryStartup(RegistryImpl.java:325) at org.apache.tapestry5.ioc.internal.RegistryWrapper.performRegistryStartup(RegistryWrapper.java:80) at org.apache.tapestry5.TapestryFilter.init(TapestryFilter.java:118) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:653) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1239) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:466) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:124) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:222) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.m
Re: @Persist objects that reference IoC services
It's a proxied service and the only one persisted. The debugger I mentioned before is XRebel, and it shows that the stored service holds a reference to both a token (ServiceProxyToken) and a creator (JustInTimeObjectCreator). The main issue here seems to be that the latter references registryShutdownHub (RegistryShutdownHubImpl) through a chain of properties, whose listeners array essentially references the entire registry. Is what I'm seeing just a defect of a freshly-out-of-beta tool or is it possible that persisting a service can carry a ~50MB (!) penalty to the session? Mihkel On 26 June 2014 19:16, Cezary Biernacki wrote: > Do you use proxied service, i.e. one defined as an interface (e.g. via > binder.bind(MyService.class, MyServiceImpl.class), not a concrete class? > > If your service is defined as a concrete class, its instance is used > directly. In such case it will be serialised using normal Java rules. > > Best regards, > Cezary > > > On Thu, Jun 26, 2014 at 4:31 PM, Mihkel Jõhvik > wrote: > > > Hi > > > > Maybe someone can help alleviate my confusion. I gather (from reading > > https://tapestry.apache.org/service-serialization.html) that IoC > services, > > when persisted, are done so using tokens. > > > > If a service is passed to a POJO and that POJO stored in a session using > > the @Persist annotation, that behaviour does not change, correct? > > > > The reason I'm asking: I'm currently looking at the session with two > > different profiling tools, one of which claims that the entire object > graph > > of the service has been stored. > > > > Mihkel > > >
Re: @Persist objects that reference IoC services
Do you use proxied service, i.e. one defined as an interface (e.g. via binder.bind(MyService.class, MyServiceImpl.class), not a concrete class? If your service is defined as a concrete class, its instance is used directly. In such case it will be serialised using normal Java rules. Best regards, Cezary On Thu, Jun 26, 2014 at 4:31 PM, Mihkel Jõhvik wrote: > Hi > > Maybe someone can help alleviate my confusion. I gather (from reading > https://tapestry.apache.org/service-serialization.html) that IoC services, > when persisted, are done so using tokens. > > If a service is passed to a POJO and that POJO stored in a session using > the @Persist annotation, that behaviour does not change, correct? > > The reason I'm asking: I'm currently looking at the session with two > different profiling tools, one of which claims that the entire object graph > of the service has been stored. > > Mihkel >
@Persist objects that reference IoC services
Hi Maybe someone can help alleviate my confusion. I gather (from reading https://tapestry.apache.org/service-serialization.html) that IoC services, when persisted, are done so using tokens. If a service is passed to a POJO and that POJO stored in a session using the @Persist annotation, that behaviour does not change, correct? The reason I'm asking: I'm currently looking at the session with two different profiling tools, one of which claims that the entire object graph of the service has been stored. Mihkel
Re: IoC / Multiple Implementations
I don't think there's anything stopping you from binding a List as a
service.
Since list is a common class, you will probably want to use marker
annotations or @InjectService to disambiguate.
Both approaches are discussed here:
http://tapestry.apache.org/defining-tapestry-ioc-services.html
On 17 Jun 2014 22:06, "Michael Leuthold"
wrote:
> Well, the scenario is a simple service-interface that returns a JSON
> array to configure a Javascript component. And depending on the input,
> the content of the JSON array looks different, that's why there are
> multiple implementations. Usually we iterate over the implementations
> and take the first result that is not null - and I just noticed that's
> exactly what the ChainBuilder does! It hides quite a bunch and does
> 'magic' :/ but I'll give it a try. I think Lances pointer to the
> OrderedConfiguration looks quite useful, too and is basically the key
> - I'll see what plays out best.
>
> However, with the given options it's a little more overhead to
> "hand-craft" the implementations to build the configuration but this
> should be do-able. Though think it would be more intuitive to just
> have the List<> injected from whatever is registered with the Binder.
>
> Thanks,
> Michael
>
>
>
> On Tue, Jun 17, 2014 at 8:51 PM, Lance Java
> wrote:
> > I tend to do the following:
> >
> > public interface FooProvider {
> >List getFoos();
> > }
> >
> > @UsesOrderedConfiguration(Foo.class)
> > public class FooProviderImpl implements FooProvider {
> >private final List foos;
> >public FooProviderImpl(List foos) { this.foos = foos; }
> >public List getFoos() { return foos; }
> > }
> >
> > Then you can @Contribute to the FooProvider to add to the list and
> @Inject
> > the FooProvider wherever you need the list.
> >
> >
> >
> > On 17 June 2014 18:21, Thiago H de Paula Figueiredo
> > wrote:
> >
> >> On Tue, 17 Jun 2014 09:54:24 -0300, Michael Leuthold <
> >> michael.leuth...@gmail.com> wrote:
> >>
> >> Hello,
> >>>
> >>> I am currently stuck with the following problem: I try to inject a
> >>> list of implementations of a certain interface but it seems it does
> >>> not work using the straight approach of injecting a
> >>> "List impls"
> >>>
> >>> Though implementations exist and a list is injected but it's just
> >>> empty. Does anyone have a hint where to look here? Maybe I need to
> >>> register that list explicitly.
> >>>
> >>
> >> Tapestry-IoC doesn't support that, at least not yet. What's your
> scenario?
> >> Usually, when we need more than one implementation of a given
> interface, we
> >> create a pipeline (
> http://tapestry.apache.org/pipelinebuilder-service.html)
> >> or chain (http://tapestry.apache.org/chainbuilder-service.html) to
> >> consolidate all these implementations as a single service. Or you can
> >> create a service that receives these service implementations as its
> >> distributed configuration and acts as a locator for it.
> >>
> >> --
> >> Thiago H. de Paula Figueiredo
> >> Tapestry, Java and Hibernate consultant and developer
> >> http://machina.com.br
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> >> For additional commands, e-mail: users-h...@tapestry.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: IoC / Multiple Implementations
Well, the scenario is a simple service-interface that returns a JSON
array to configure a Javascript component. And depending on the input,
the content of the JSON array looks different, that's why there are
multiple implementations. Usually we iterate over the implementations
and take the first result that is not null - and I just noticed that's
exactly what the ChainBuilder does! It hides quite a bunch and does
'magic' :/ but I'll give it a try. I think Lances pointer to the
OrderedConfiguration looks quite useful, too and is basically the key
- I'll see what plays out best.
However, with the given options it's a little more overhead to
"hand-craft" the implementations to build the configuration but this
should be do-able. Though think it would be more intuitive to just
have the List<> injected from whatever is registered with the Binder.
Thanks,
Michael
On Tue, Jun 17, 2014 at 8:51 PM, Lance Java wrote:
> I tend to do the following:
>
> public interface FooProvider {
>List getFoos();
> }
>
> @UsesOrderedConfiguration(Foo.class)
> public class FooProviderImpl implements FooProvider {
>private final List foos;
>public FooProviderImpl(List foos) { this.foos = foos; }
>public List getFoos() { return foos; }
> }
>
> Then you can @Contribute to the FooProvider to add to the list and @Inject
> the FooProvider wherever you need the list.
>
>
>
> On 17 June 2014 18:21, Thiago H de Paula Figueiredo
> wrote:
>
>> On Tue, 17 Jun 2014 09:54:24 -0300, Michael Leuthold <
>> michael.leuth...@gmail.com> wrote:
>>
>> Hello,
>>>
>>> I am currently stuck with the following problem: I try to inject a
>>> list of implementations of a certain interface but it seems it does
>>> not work using the straight approach of injecting a
>>> "List impls"
>>>
>>> Though implementations exist and a list is injected but it's just
>>> empty. Does anyone have a hint where to look here? Maybe I need to
>>> register that list explicitly.
>>>
>>
>> Tapestry-IoC doesn't support that, at least not yet. What's your scenario?
>> Usually, when we need more than one implementation of a given interface, we
>> create a pipeline (http://tapestry.apache.org/pipelinebuilder-service.html)
>> or chain (http://tapestry.apache.org/chainbuilder-service.html) to
>> consolidate all these implementations as a single service. Or you can
>> create a service that receives these service implementations as its
>> distributed configuration and acts as a locator for it.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Tapestry, Java and Hibernate consultant and developer
>> http://machina.com.br
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IoC / Multiple Implementations
I tend to do the following:
public interface FooProvider {
List getFoos();
}
@UsesOrderedConfiguration(Foo.class)
public class FooProviderImpl implements FooProvider {
private final List foos;
public FooProviderImpl(List foos) { this.foos = foos; }
public List getFoos() { return foos; }
}
Then you can @Contribute to the FooProvider to add to the list and @Inject
the FooProvider wherever you need the list.
On 17 June 2014 18:21, Thiago H de Paula Figueiredo
wrote:
> On Tue, 17 Jun 2014 09:54:24 -0300, Michael Leuthold <
> michael.leuth...@gmail.com> wrote:
>
> Hello,
>>
>> I am currently stuck with the following problem: I try to inject a
>> list of implementations of a certain interface but it seems it does
>> not work using the straight approach of injecting a
>> "List impls"
>>
>> Though implementations exist and a list is injected but it's just
>> empty. Does anyone have a hint where to look here? Maybe I need to
>> register that list explicitly.
>>
>
> Tapestry-IoC doesn't support that, at least not yet. What's your scenario?
> Usually, when we need more than one implementation of a given interface, we
> create a pipeline (http://tapestry.apache.org/pipelinebuilder-service.html)
> or chain (http://tapestry.apache.org/chainbuilder-service.html) to
> consolidate all these implementations as a single service. Or you can
> create a service that receives these service implementations as its
> distributed configuration and acts as a locator for it.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: IoC / Multiple Implementations
On Tue, 17 Jun 2014 09:54:24 -0300, Michael Leuthold wrote: Hello, I am currently stuck with the following problem: I try to inject a list of implementations of a certain interface but it seems it does not work using the straight approach of injecting a "List impls" Though implementations exist and a list is injected but it's just empty. Does anyone have a hint where to look here? Maybe I need to register that list explicitly. Tapestry-IoC doesn't support that, at least not yet. What's your scenario? Usually, when we need more than one implementation of a given interface, we create a pipeline (http://tapestry.apache.org/pipelinebuilder-service.html) or chain (http://tapestry.apache.org/chainbuilder-service.html) to consolidate all these implementations as a single service. Or you can create a service that receives these service implementations as its distributed configuration and acts as a locator for it. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
IoC / Multiple Implementations
Hello, I am currently stuck with the following problem: I try to inject a list of implementations of a certain interface but it seems it does not work using the straight approach of injecting a "List impls" Though implementations exist and a list is injected but it's just empty. Does anyone have a hint where to look here? Maybe I need to register that list explicitly. Thanks, Michael - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry IOC: Multiple bindings for same interface
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 way" of doing what you want is to make multiple > contributions to a single service and inject the single service. >
Re: Tapestry IOC: Multiple bindings for same interface
I think the "tapestry way" of doing what you want is to make multiple contributions to a single service and inject the single service.
Re: Tapestry IOC: Multiple bindings for same interface
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 developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Tapestry IOC: Multiple bindings for same interface
Is it possible in T5 to inject multiple services which implemented same interface into array field? I.e: @Inject private SomeService[] services; - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry IOC / Autobuild / Advise Question
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) {
binder.bind(actorClass).scope("prototype");
}
}
If you put all of your classes in the same package you could use
ClassNameLocator to look them up.
That's a really nice, elegant solution! :)
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry IOC / Autobuild / Advise Question
> 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 you put all of your classes in the same package you could use
ClassNameLocator to look them up.
On 11 February 2014 17:50, Thiago H de Paula Figueiredo
wrote:
> 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 correct scope
>> plus the correct marker (to trigger the method advise). Due to the
>> architecture of Akka, you then have to create the actual actors using
>> actorSystem.actorOf() using either an indirect actor producer or an
>> instance of the actor service defined before.
>>
>
> You can declare services based on objects you instantiate yourself. Just
> create a buildXXX() method. Of course, you'll need to create one for each
> actor.
>
>
> The solution with autobuild() is much more elegant,
>>
>
> Have you tried using the proxy() method instead of autobuild? I'm not sure
> it'll work, but that's something I'd try. After all, the whole Tapestry-IoC
> implementation of decoration and aspects are based on proxies.
>
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: Tapestry IOC / Autobuild / Advise Question
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 correct scope plus the correct marker (to trigger the method advise). Due to the architecture of Akka, you then have to create the actual actors using actorSystem.actorOf() using either an indirect actor producer or an instance of the actor service defined before. You can declare services based on objects you instantiate yourself. Just create a buildXXX() method. Of course, you'll need to create one for each actor. The solution with autobuild() is much more elegant, Have you tried using the proxy() method instead of autobuild? I'm not sure it'll work, but that's something I'd try. After all, the whole Tapestry-IoC implementation of decoration and aspects are based on proxies. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry IOC / Autobuild / Advise Question
Thiago, every time you call ObjectLocator.getService() you get a singleton. Every time you call ObjectLocator.autobuild() you get a new object.
RE: Tapestry IOC / Autobuild / Advise Question
Hi Thiago, 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 correct scope plus the correct marker (to trigger the method advise). Due to the architecture of Akka, you then have to create the actual actors using actorSystem.actorOf() using either an indirect actor producer or an instance of the actor service defined before. The solution with autobuild() is much more elegant, with the exception that you need to handle the transactions manually. For me it feels, that actors are more similar to pages than to real services. They act (sic) as glue code (integration layer) for high level business code. I think I will go back to the autobuild() solution and manage the transactions manually (or outside Akka). Thanks 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, 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/archive/v/NzHgIqXAifXhNB7jPRIc I don't think that's controversial at all. The thread had a scenario which is very different from yours. You need decoration and advice, so you need to make it a service. The scenario in the thread wanted that an object that isn't a proxy to be returned, so my answer wass based on this requirement. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry IOC / Autobuild / Advise Question
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/archive/v/NzHgIqXAifXhNB7jPRIc I don't think that's controversial at all. The thread had a scenario which is very different from yours. You need decoration and advice, so you need to make it a service. The scenario in the thread wanted that an object that isn't a proxy to be returned, so my answer wass based on this requirement. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry IOC / Autobuild / Advise Question
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 singleton, but that's just a implementation detail. A perthread service will use a different instance for each thread. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Tapestry IOC / Autobuild / Advise Question
Hi Lance, hi Thiago, 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/archive/v/NzHgIqXAifXhNB7jPRIc It is recommended to either use autobuild() or a factory. Using Plastic doesn't seem to work either, because I end up with a ClassInstantiator which let me create a transformed object (without any dependencies injected). Is there a way to get the transformed class out of Plastic and use it within autobuild? Or is it possible 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: Tapestry IOC / Autobuild / Advise Question 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. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry IOC / Autobuild / Advise Question
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.
Re: Tapestry IOC / Autobuild / Advise Question
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.
Re: Tapestry IOC / Autobuild / Advise Question
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 interface. I've been using it on perthread services a lot without any issues. I think the solution is to create a new Tapestry-IoC scope, similar to Spring's prototype one (basically, create a new object everytime injection is done) and turn the actor objects into services. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry IOC / Autobuild / Advise Question
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)
Tapestry IOC / Autobuild / Advise Question
Hi all,
I have a quick question concerning Tapestry IOC. I'm currently integrating Akka
into one of my applications. In order to use it with a DI container, I created
a IndirectActorProducer which uses the autobuild() method of ObjectLocator, in
order to create a new actor object whenever produce is triggered (a requirement
by Akka). Service injections are also fulfilled by autobuild(). So far so good.
Then I tried to use the @CommitAfter annotation from JPA module. Because the of
the fact, that the objects created with autobuild() aren't services, the commit
isn't triggered. @Match("*Actor") advisor doesn't work as well.
How can advise a method in an object created with autobuild() ? Do I need to
create a new IOC scope or can I use Plastic somehow?
Docs to use Akka with DI:
http://doc.akka.io/docs/akka/2.2.3/java/untyped-actors.html#Dependency_Injection
Thanks a lot in advance for all your inputs!
Best,
Thilo
Re: ScheduledExecutorService in tapestry ioc
Thanks Dmitry, works perfect :).
On 06.02.2014 16:11, Dmitry Gusev wrote:
You can try anjlab-tapestry-quartz from here:
https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-quartz
On Thu, Feb 6, 2014 at 2:46 PM, Matthias wrote:
Hi, I need to write a service where jobs can be added and should executed
after a given delay. After execution they are finished, so periodical
execution is not required. I prefer to user the ScheduledExecutorService
for this task.
The question is now, how do I use my @Inject objects in the thread? Just
passing them is not working (hibernate session is invalid). I read some
stuff like http://wiki.apache.org/tapestry/Tapestry5HowToRunTaskInThreadbut it
does'nt help me because I don't invoke the thread myself, the
scheduler is doing it. Also the other tapestry classes like the
ParallelExecutor or PeriodicExecutor doesn't seem to fit.
Any suggestions?
@Scope(ScopeConstants.DEFAULT)
public class MyServiceImpl implements MyService {
@Inject
MyDAO myDAO;
private ScheduledExecutorService scheduler = Executors.
newScheduledThreadPool(4);
public void addJob(Job job, long executeDelay) {
scheduler.schedule(new JobTask(job, myDAO), executeDelay);
}
public static class JobTask implements Runnable {
// some class members
public JobTask(MyDAO myDAO, Job job) {
this.myDAO = myDAO;
this.job = job;
}
@Override
public void run() {
// ...
Object result = myDAO.getSomethingFromJob(job);
// ...
}
}
}
Thanks,
Matthias
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ScheduledExecutorService in tapestry ioc
You can try anjlab-tapestry-quartz from here:
https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-quartz
On Thu, Feb 6, 2014 at 2:46 PM, Matthias wrote:
> Hi, I need to write a service where jobs can be added and should executed
> after a given delay. After execution they are finished, so periodical
> execution is not required. I prefer to user the ScheduledExecutorService
> for this task.
>
> The question is now, how do I use my @Inject objects in the thread? Just
> passing them is not working (hibernate session is invalid). I read some
> stuff like http://wiki.apache.org/tapestry/Tapestry5HowToRunTaskInThreadbut
> it does'nt help me because I don't invoke the thread myself, the
> scheduler is doing it. Also the other tapestry classes like the
> ParallelExecutor or PeriodicExecutor doesn't seem to fit.
>
> Any suggestions?
>
> @Scope(ScopeConstants.DEFAULT)
> public class MyServiceImpl implements MyService {
>
> @Inject
> MyDAO myDAO;
>
> private ScheduledExecutorService scheduler = Executors.
> newScheduledThreadPool(4);
>
> public void addJob(Job job, long executeDelay) {
> scheduler.schedule(new JobTask(job, myDAO), executeDelay);
> }
>
> public static class JobTask implements Runnable {
> // some class members
> public JobTask(MyDAO myDAO, Job job) {
> this.myDAO = myDAO;
> this.job = job;
> }
>
> @Override
> public void run() {
> // ...
> Object result = myDAO.getSomethingFromJob(job);
> // ...
> }
> }
> }
>
> Thanks,
> Matthias
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
ScheduledExecutorService in tapestry ioc
Hi, I need to write a service where jobs can be added and should
executed after a given delay. After execution they are finished, so
periodical execution is not required. I prefer to user the
ScheduledExecutorService for this task.
The question is now, how do I use my @Inject objects in the thread? Just
passing them is not working (hibernate session is invalid). I read some
stuff like http://wiki.apache.org/tapestry/Tapestry5HowToRunTaskInThread
but it does'nt help me because I don't invoke the thread myself, the
scheduler is doing it. Also the other tapestry classes like the
ParallelExecutor or PeriodicExecutor doesn't seem to fit.
Any suggestions?
@Scope(ScopeConstants.DEFAULT)
public class MyServiceImpl implements MyService {
@Inject
MyDAO myDAO;
private ScheduledExecutorService scheduler =
Executors.newScheduledThreadPool(4);
public void addJob(Job job, long executeDelay) {
scheduler.schedule(new JobTask(job, myDAO), executeDelay);
}
public static class JobTask implements Runnable {
// some class members
public JobTask(MyDAO myDAO, Job job) {
this.myDAO = myDAO;
this.job = job;
}
@Override
public void run() {
// ...
Object result = myDAO.getSomethingFromJob(job);
// ...
}
}
}
Thanks,
Matthias
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
ScheduledExecutorService in tapestry ioc service
Hi, I need to write a service where jobs can be added and should
executed after a given delay. After execution they are finished, so
periodical execution is not required. I prefer to user the
ScheduledExecutorService for this task.
The question is now, how do I use my @Inject objects in the thread? Just
passing them is not working (hibernate session is invalid). I read some
stuff like http://wiki.apache.org/tapestry/Tapestry5HowToRunTaskInThread
but it does'nt help me because I don't invoke the thread myself, the
scheduler is doing it. Also the other tapestry classes like the
ParallelExecutor or PeriodicExecutor doesn't seem to fit.
Any suggestions?
@Scope(ScopeConstants.DEFAULT)
public class MyServiceImpl implements MyService {
@Inject
MyDAO myDAO;
private ScheduledExecutorService scheduler =
Executors.newScheduledThreadPool(4);
public void addJob(Job job, long executeDelay) {
scheduler.schedule(new JobTask(job, myDAO), executeDelay);
}
public static class JobTask implements Runnable {
// some class members
public JobTask(MyDAO myDAO, Job job) {
this.myDAO = myDAO;
this.job = job;
}
@Override
public void run() {
// ...
Object result = myDAO.getSomethingFromJob(job);
// ...
}
}
}
Thanks, Matthias
Re: [Might be OT] What is the difference between J2EE CDI and Tapestry's IoC ?
On Thu, 09 Jan 2014 13:58:45 -0200, Nourredine K. wrote: Hi, Nourredine! Hi Thiago! Hi! I saw that : ) thank you for fixing it Thank everyone that contributed for the campaign and allowed me to have time to work on the Tapestry codebase. :) Converting a CDI bean or an EJB into a tapestry service and making you thus benefit of the annotation-based CDI and transactionnal stuff inside a tapestry service is already possible[1]. The opposite is not at the moment, but could be worked around if you declare/contribute to your service by instantiating the class with CDI [1] ? https://github.com/got5/tapestry-cdi#using-cdi-beans-as-tapestry-services I haven't checked myself, but I don't think that covers my dream scenario, as the object is instantiated by CDI, not Tapestry, so distributed configuration is lost. BTW, I take your suggestion into account :) Thank you very much. :) -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Might be OT] What is the difference between J2EE CDI and Tapestry's IoC ?
> Hi, Nourredine! Hi Thiago! > > I couldn't check tapestry-cdi (not even CDI itself yet, sigh), but I have a > dream scenario which I don't know whether tapestry-cdi supports it. If not, > consider it a suggestion. :) > > Tapestry-IoC has distributed configuration support, which is wonderful for > creating very flexible applications and libraries. In addition, it has an > incredibly easy to use AOP (advice and decoration) support. Totally agree ! > On the other hand, it doesn't have complex transaction handling support like > Spring and > CDI do. I think it's not feasible to implement it in Tapestry-IoC. It would > demand developer time which we don't have. In addition, until some days ago, > the service proxies generated by T-IoC didn't have the annotations the > service implementation does, but the Month of Tapestry was able to fix that > limitation. ;) I saw that : ) thank you for fixing it > So my dream scenario is to create Tapestry-IoC services, somehow pass them > to CDI so we can use all the annotation-based CDI and EJB stuff like > transaction handling and RPC, and finally using these CDI-wrapped T-IoC > services in Tapestry or anywhere else just like they were vanilla T-IoC > services. Converting a CDI bean or an EJB into a tapestry service and making you thus benefit of the annotation-based CDI and transactionnal stuff inside a tapestry service is already possible[1]. The opposite is not at the moment, but could be worked around if you declare/contribute to your service by instantiating the class with CDI [1] ? BTW, I take your suggestion into account :) Note that CDI 1.1 (@Transactional annotation) will be part of jee7 [1] https://github.com/got5/tapestry-cdi#using-cdi-beans-as-tapestry-services - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Might be OT] What is the difference between J2EE CDI and Tapestry's IoC ?
On Wed, 08 Jan 2014 08:22:50 -0200, Nourredine K. wrote: Hi, Hi, Nourredine! The idea is to make CDI and tapestry-ioc work together without conflict and let you use existing projects based on CDI with Tapestry. I couldn't check tapestry-cdi (not even CDI itself yet, sigh), but I have a dream scenario which I don't know whether tapestry-cdi supports it. If not, consider it a suggestion. :) Tapestry-IoC has distributed configuration support, which is wonderful for creating very flexible applications and libraries. In addition, it has an incredibly easy to use AOP (advice and decoration) support. On the other hand, it doesn't have complex transaction handling support like Spring and CDI do. I think it's not feasible to implement it in Tapestry-IoC. It would demand developer time which we don't have. In addition, until some days ago, the service proxies generated by T-IoC didn't have the annotations the service implementation does, but the Month of Tapestry was able to fix that limitation. ;) So my dream scenario is to create Tapestry-IoC services, somehow pass them to CDI so we can use all the annotation-based CDI and EJB stuff like transaction handling and RPC, and finally using these CDI-wrapped T-IoC services in Tapestry or anywhere else just like they were vanilla T-IoC services. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Might be OT] What is the difference between J2EE CDI and Tapestry's IoC ?
Hi, I can tell you more about the tapestry-cdi module. It's intented to make a bridge between CDI and tapestry to ease the integration into a jee stack (like what tapestry-spring provides for Spring). The idea is to make CDI and tapestry-ioc work together without conflict and let you use existing projects based on CDI with Tapestry. So you can inject CDI beans into pages, components[1] and tapestry services[2]. But you can also "convert" existing CDI beans into tapestry services[3]. For common features (for instance : @Qualifier/@Named vs @Marker) , there is no pb as you can use any of the two. In CDI 1.1, we will see some interesting features such as the @ConversationScope, @Tansactional and @Secure annotations. I would love to see them integrated in a next tapestry-cdi release when the spec will be implemented by application servers (for the time, only Glassfish 4) [1] https://github.com/got5/tapestry-cdi#usage [2] https://github.com/got5/tapestry-cdi#using-tapestry-services-with-cdi-beans [3] https://github.com/got5/tapestry-cdi#using-cdi-beans-as-tapestry-services Nourredine. 2014/1/7 Muhammad Gelbana : > Thanks a lot for your time taken to collect these links, I appreciate it. > I don't mean to revive a debate, I'll go ahead and read these threads, > thanks again :) > > *-* > *Muhammad Gelbana* > http://www.linkedin.com/in/mgelbana > > > On Wed, Jan 8, 2014 at 12:33 AM, Lenny Primak wrote: > >> This is somewhat a sensitive subject: >> >> >> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Merits-of-Tapestry-IOC-td5721445.html >> >> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html >> >> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Differences-between-Tapestry-IoC-and-J2EE-6-CDI-td3412912.html >> >> On Jan 7, 2014, at 4:42 PM, Muhammad Gelbana wrote: >> >> > The subject says it all, what is the different between CDI (Context and >> > Dependency Injection) and Tapestry's IoC ? There is a >> > bug\task< >> https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=bf2c8a4f09152ef0f10ef788ed17370b540a2670 >> >to >> > be implemented in Tapestry 5.4 that implies adding CDI support to >> > Tapestry. >> > >> > Would someone kindly explain what is the difference between Tapestry's >> IoC >> > and J2EE's CDI ? >> > >> > Is it like CDI enables the injection of J2EE specific standards such as >> > WebServiceContext< >> http://docs.oracle.com/javase/7/docs/api/javax/xml/ws/WebServiceContext.html >> > >> > which >> > is not a Tapestry service ? >> > >> > *-* >> > *Muhammad Gelbana* >> > http://www.linkedin.com/in/mgelbana >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Might be OT] What is the difference between J2EE CDI and Tapestry's IoC ?
Thanks a lot for your time taken to collect these links, I appreciate it. I don't mean to revive a debate, I'll go ahead and read these threads, thanks again :) *-* *Muhammad Gelbana* http://www.linkedin.com/in/mgelbana On Wed, Jan 8, 2014 at 12:33 AM, Lenny Primak wrote: > This is somewhat a sensitive subject: > > > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Merits-of-Tapestry-IOC-td5721445.html > > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html > > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Differences-between-Tapestry-IoC-and-J2EE-6-CDI-td3412912.html > > On Jan 7, 2014, at 4:42 PM, Muhammad Gelbana wrote: > > > The subject says it all, what is the different between CDI (Context and > > Dependency Injection) and Tapestry's IoC ? There is a > > bug\task< > https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=bf2c8a4f09152ef0f10ef788ed17370b540a2670 > >to > > be implemented in Tapestry 5.4 that implies adding CDI support to > > Tapestry. > > > > Would someone kindly explain what is the difference between Tapestry's > IoC > > and J2EE's CDI ? > > > > Is it like CDI enables the injection of J2EE specific standards such as > > WebServiceContext< > http://docs.oracle.com/javase/7/docs/api/javax/xml/ws/WebServiceContext.html > > > > which > > is not a Tapestry service ? > > > > *-* > > *Muhammad Gelbana* > > http://www.linkedin.com/in/mgelbana > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: [Might be OT] What is the difference between J2EE CDI and Tapestry's IoC ?
This is somewhat a sensitive subject: http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Merits-of-Tapestry-IOC-td5721445.html http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/First-stab-at-CDI-module-for-tapestry-td4469281.html http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Differences-between-Tapestry-IoC-and-J2EE-6-CDI-td3412912.html On Jan 7, 2014, at 4:42 PM, Muhammad Gelbana wrote: > The subject says it all, what is the different between CDI (Context and > Dependency Injection) and Tapestry's IoC ? There is a > bug\task<https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=bf2c8a4f09152ef0f10ef788ed17370b540a2670>to > be implemented in Tapestry 5.4 that implies adding CDI support to > Tapestry. > > Would someone kindly explain what is the difference between Tapestry's IoC > and J2EE's CDI ? > > Is it like CDI enables the injection of J2EE specific standards such as > WebServiceContext<http://docs.oracle.com/javase/7/docs/api/javax/xml/ws/WebServiceContext.html> > which > is not a Tapestry service ? > > *-* > *Muhammad Gelbana* > http://www.linkedin.com/in/mgelbana - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
[Might be OT] What is the difference between J2EE CDI and Tapestry's IoC ?
The subject says it all, what is the different between CDI (Context and Dependency Injection) and Tapestry's IoC ? There is a bug\task<https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;a=commit;h=bf2c8a4f09152ef0f10ef788ed17370b540a2670>to be implemented in Tapestry 5.4 that implies adding CDI support to Tapestry. Would someone kindly explain what is the difference between Tapestry's IoC and J2EE's CDI ? Is it like CDI enables the injection of J2EE specific standards such as WebServiceContext<http://docs.oracle.com/javase/7/docs/api/javax/xml/ws/WebServiceContext.html> which is not a Tapestry service ? *-* *Muhammad Gelbana* http://www.linkedin.com/in/mgelbana
Standalone IOC and service overrides
Hi,
we love the IOC and are using it in our standalone Java applications as
well as our web applications. I do however have a problem with overriding
services. When using the suggestions from the cookbook (
http://tapestry.apache.org/ioc-cookbook-overriding-ioc-services.html) to
override a service, I find that the the service is not overridden using the
getService method on the registry. I've been through the IOC code and I
could see that the ServiceOverride service is called from the
MasterObjectProvider but not from elsewhere. Based on that I tried to use
the getObject() method on the registry, and that does indeed give me the
overridden service. I found this behaviour rather unexpected, so I assume
I'm missing something.
We use getService in a lot of places, and it would be quite a change to
have to use getObject everywhere instead. As we have markers on our
services, the getService interface is also easier to use.
So my question is: why the difference between getService and getObject? And
which one should we be using?
Please see below a junit test that demonstrates this behaviour. I'd really
appreciate any enlightenment!
Cheers,
Adriaan
import static org.junit.Assert.assertEquals;
import org.apache.tapestry5.ioc.MappedConfiguration;
import org.apache.tapestry5.ioc.Registry;
import org.apache.tapestry5.ioc.RegistryBuilder;
import org.apache.tapestry5.ioc.ServiceBinder;
import org.apache.tapestry5.ioc.annotations.Contribute;
import org.apache.tapestry5.ioc.annotations.SubModule;
import org.apache.tapestry5.ioc.internal.NullAnnotationProvider;
import org.apache.tapestry5.ioc.services.ServiceOverride;
import org.junit.Test;
public class IocTest {
public interface Simple {
String getString();
}
public static class SimpleImpl implements Simple {
@Override
public String getString() {
return "foo";
}
}
public static class SimpleOverrideImpl implements Simple {
@Override
public String getString() {
return "bar";
}
}
public static class DefaultAppModule {
public static void bind(ServiceBinder binder) {
binder.bind(Simple.class, SimpleImpl.class);
}
}
@SubModule(DefaultAppModule.class)
public static class OverrideAppModule {
@Contribute(ServiceOverride.class)
public static void testOverrides(
MappedConfiguration, Object> configuration) {
configuration.addInstance(Simple.class,
SimpleOverrideImpl.class);
}
}
@Test
public void testWithoutOverride() {
RegistryBuilder builder = new RegistryBuilder();
builder.add(DefaultAppModule.class);
Registry registry = builder.build();
registry.performRegistryStartup();
Simple simple = registry.getService(Simple.class);
assertEquals("foo", simple.getString());
registry.cleanupThread();
registry.shutdown();
}
@Test
public void testWithOverride() {
RegistryBuilder builder = new RegistryBuilder();
builder.add(OverrideAppModule.class);
Registry registry = builder.build();
registry.performRegistryStartup();
Simple simple = registry.getService(Simple.class);
// !FAILS!
assertEquals("bar", simple.getString());
registry.cleanupThread();
registry.shutdown();
}
@Test
public void testWithOverrideAndObjectProvider() {
RegistryBuilder builder = new RegistryBuilder();
builder.add(OverrideAppModule.class);
Registry registry = builder.build();
registry.performRegistryStartup();
Simple simple = registry.getObject(Simple.class,
new NullAnnotationProvider());
// SUCCEEDS
assertEquals("bar", simple.getString());
registry.cleanupThread();
registry.shutdown();
}
}
Re: Tapetsry IoC starting a class with background task that uses an injected service
>
> That's my preferred way to do injection in services and it avoids problems
> like you're having
If you do that, you'll have to refactor your constructor parameters and
assignment statement if you remove\add a new service. It should be a lot
easier to use
@Inject
private MyService svc;
If using a constructor makes sure that all passed services (as parameters
to the constructor) are proxied and ready to be instantiated, then so
should injecting a service as a class member (i.e. as the 2 lines of code I
wrote earlier), they should behave the same, else it would be a bug,
exactly like you said.
The only case I know where one MUST use a service's constructor to pass a
dependency, is when you need the logger service injected.
*-*
*Muhammad Gelbana*
http://www.linkedin.com/in/mgelbana
On Fri, Nov 22, 2013 at 7:55 PM, Dmitry Gusev wrote:
> @EagerLoad is for service builder methods:
>
> http://tapestry.apache.org/5.3.7/apidocs/org/apache/tapestry5/ioc/annotations/EagerLoad.html
>
> Don't use TimeTask, use Tapestry's PeriodicExecutor with
>
> http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Startup.html
>
>
>
>
> On Fri, Nov 22, 2013 at 9:47 PM, John wrote:
>
> > I need my setup method to run when this class is instantiated but log is
> > null so mailDAO will also be null.
> >
> > John
> >
> >
> > public class EmailReceiverUtil {
> >
> > public static final int SHOW_MESSAGES = 1;
> > public static final int CLEAR_MESSAGES = 2;
> > public static final int SHOW_AND_CLEAR =
> > SHOW_MESSAGES + CLEAR_MESSAGES;
> > /**
> > * The log.
> > */
> > @Inject
> > private Logger log;
> > @Inject
> > private MailDAO mailDAO;
> > /**
> > * Mail properties
> > */
> > Properties props = new Properties();
> > /**
> > * Timer for background task;
> > */
> > Timer timer = new Timer();
> >
> > public EmailReceiverUtil() {
> > System.out.println("EmailReceiverUtil instantiated");
> > }
> >
> > @EagerLoad
> > public void setup() {
> > // configure properties
> > props.put("mail.user", "John");
> > props.put("mail.host", "diskstation");
> > props.put("mail.debug", "false");
> > props.put("mail.store.protocol", "pop3");
> > timer.schedule(new MailReceiverThread(), 1000, 6);
> > log.info("Email Receiver running");
> > }
> >
> > private void checkInbox(int mode)
> > ...
> > }
> >
> > private boolean processPlainTextMessage(final String from, final
> > String to,
> > final String subject, final String message) {
> > try {
> > String messageText = message;
> > return mailDAO.processIncomingMail(from, to, messageText);
> > } catch (DAOException ex) {
> > ex.printStackTrace();
> > }
> > return false;
> > }
> >
> > class MailReceiverThread extends TimerTask {
> >
> > public void run() {
> > try {
> > checkInbox(CLEAR_MESSAGES);
> > } catch (Exception ex) {
> > ex.printStackTrace();
> > }
> > }
> > }
> > }
> >
> > - Original Message -
> > From: Thiago H de Paula Figueiredo
> > To: Tapestry users
> > Sent: Friday, November 22, 2013 5:26 PM
> > Subject: Re: Tapetsry IoC starting a class with background task that
> > uses an injected service
> >
> >
> > On Fri, 22 Nov 2013 14:03:10 -0200, John wrote:
> >
> > > How do I get this class to load when I start my app and make sure the
> > > injected services are set? With EagerLoad the class gets instantiated
> > > but of course the services are null.
> >
> > This statement is not correct as far as I know. Tapestry-IoC injects
> > service proxies (when the service is defined by an interface), so the
> > dependencies may not even be initialized yet, but, when you first call
> > them, they will be initialized.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Tapestry, Java and Hibernate consultant and developer
> > http://machina.com.br
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
Re: Tapetsry IoC starting a class with background task that uses an injected service
@EagerLoad is for service builder methods:
http://tapestry.apache.org/5.3.7/apidocs/org/apache/tapestry5/ioc/annotations/EagerLoad.html
Don't use TimeTask, use Tapestry's PeriodicExecutor with
http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Startup.html
On Fri, Nov 22, 2013 at 9:47 PM, John wrote:
> I need my setup method to run when this class is instantiated but log is
> null so mailDAO will also be null.
>
> John
>
>
> public class EmailReceiverUtil {
>
> public static final int SHOW_MESSAGES = 1;
> public static final int CLEAR_MESSAGES = 2;
> public static final int SHOW_AND_CLEAR =
> SHOW_MESSAGES + CLEAR_MESSAGES;
> /**
> * The log.
> */
> @Inject
> private Logger log;
> @Inject
> private MailDAO mailDAO;
> /**
> * Mail properties
> */
> Properties props = new Properties();
> /**
> * Timer for background task;
> */
> Timer timer = new Timer();
>
> public EmailReceiverUtil() {
> System.out.println("EmailReceiverUtil instantiated");
> }
>
> @EagerLoad
> public void setup() {
> // configure properties
> props.put("mail.user", "John");
> props.put("mail.host", "diskstation");
> props.put("mail.debug", "false");
> props.put("mail.store.protocol", "pop3");
> timer.schedule(new MailReceiverThread(), 1000, 6);
> log.info("Email Receiver running");
> }
>
> private void checkInbox(int mode)
> ...
> }
>
> private boolean processPlainTextMessage(final String from, final
> String to,
> final String subject, final String message) {
> try {
> String messageText = message;
> return mailDAO.processIncomingMail(from, to, messageText);
> } catch (DAOException ex) {
> ex.printStackTrace();
> }
> return false;
> }
>
> class MailReceiverThread extends TimerTask {
>
> public void run() {
> try {
> checkInbox(CLEAR_MESSAGES);
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> }
> }
> }
>
> - Original Message -
> From: Thiago H de Paula Figueiredo
> To: Tapestry users
> Sent: Friday, November 22, 2013 5:26 PM
> Subject: Re: Tapetsry IoC starting a class with background task that
> uses an injected service
>
>
> On Fri, 22 Nov 2013 14:03:10 -0200, John wrote:
>
> > How do I get this class to load when I start my app and make sure the
> > injected services are set? With EagerLoad the class gets instantiated
> > but of course the services are null.
>
> This statement is not correct as far as I know. Tapestry-IoC injects
> service proxies (when the service is defined by an interface), so the
> dependencies may not even be initialized yet, but, when you first call
> them, they will be initialized.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Tapetsry IoC starting a class with background task that uses an injected service
On Fri, 22 Nov 2013 15:47:10 -0200, John wrote: I need my setup method to run when this class is instantiated but log is null so mailDAO will also be null. Weird. Maybe the @EagerLoad-annotated method is being called before the field injection is done. If that's really the case, that's a bug. By the way, why don't you receive the dependencies through the consturctor? That's my preferred way to do injection in services and it avoids problems like you're having. I don't think I ever used @Inject in a service. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapetsry IoC starting a class with background task that uses an injected service
I need my setup method to run when this class is instantiated but log is null
so mailDAO will also be null.
John
public class EmailReceiverUtil {
public static final int SHOW_MESSAGES = 1;
public static final int CLEAR_MESSAGES = 2;
public static final int SHOW_AND_CLEAR =
SHOW_MESSAGES + CLEAR_MESSAGES;
/**
* The log.
*/
@Inject
private Logger log;
@Inject
private MailDAO mailDAO;
/**
* Mail properties
*/
Properties props = new Properties();
/**
* Timer for background task;
*/
Timer timer = new Timer();
public EmailReceiverUtil() {
System.out.println("EmailReceiverUtil instantiated");
}
@EagerLoad
public void setup() {
// configure properties
props.put("mail.user", "John");
props.put("mail.host", "diskstation");
props.put("mail.debug", "false");
props.put("mail.store.protocol", "pop3");
timer.schedule(new MailReceiverThread(), 1000, 6);
log.info("Email Receiver running");
}
private void checkInbox(int mode)
...
}
private boolean processPlainTextMessage(final String from, final String to,
final String subject, final String message) {
try {
String messageText = message;
return mailDAO.processIncomingMail(from, to, messageText);
} catch (DAOException ex) {
ex.printStackTrace();
}
return false;
}
class MailReceiverThread extends TimerTask {
public void run() {
try {
checkInbox(CLEAR_MESSAGES);
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
}
- Original Message -
From: Thiago H de Paula Figueiredo
To: Tapestry users
Sent: Friday, November 22, 2013 5:26 PM
Subject: Re: Tapetsry IoC starting a class with background task that uses an
injected service
On Fri, 22 Nov 2013 14:03:10 -0200, John wrote:
> How do I get this class to load when I start my app and make sure the
> injected services are set? With EagerLoad the class gets instantiated
> but of course the services are null.
This statement is not correct as far as I know. Tapestry-IoC injects
service proxies (when the service is defined by an interface), so the
dependencies may not even be initialized yet, but, when you first call
them, they will be initialized.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapetsry IoC starting a class with background task that uses an injected service
On Fri, 22 Nov 2013 14:03:10 -0200, John wrote: How do I get this class to load when I start my app and make sure the injected services are set? With EagerLoad the class gets instantiated but of course the services are null. This statement is not correct as far as I know. Tapestry-IoC injects service proxies (when the service is defined by an interface), so the dependencies may not even be initialized yet, but, when you first call them, they will be initialized. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapetsry IoC starting a class with background task that uses an injected service
I don't believe eager loading loads a service without it's dependencies injected. Try starting your background service in a @Startup annotation method in your module's class. Starting your service just means calling one of it's methods. *-* *Muhammad Gelbana* http://www.linkedin.com/in/mgelbana On Fri, Nov 22, 2013 at 6:03 PM, John wrote: > I have a utility class that recieves emails with a background TimerTask > that needs to invoke a method on one of my injected DAOs to store the > messages in the db. > > How do I get this class to load when I start my app and make sure the > injected services are set? With EagerLoad the class gets instantiated but > of course the services are null. > > John
Re: Tapetsry IoC starting a class with background task that uses an injected service
Put it to ParallelExecutor? http://tapestry.apache.org/parallel-execution.html http://blog.tapestry5.de/index.php/2011/09/18/scheduling-jobs-with-tapestry/ There's also Quartz scheduler support: https://github.com/anjlab/anjlab-tapestry-commons/tree/master/anjlab-tapestry-quartz On Fri, Nov 22, 2013 at 8:03 PM, John wrote: > I have a utility class that recieves emails with a background TimerTask > that needs to invoke a method on one of my injected DAOs to store the > messages in the db. > > How do I get this class to load when I start my app and make sure the > injected services are set? With EagerLoad the class gets instantiated but > of course the services are null. > > John -- Dmitry Gusev AnjLab Team http://anjlab.com
Tapetsry IoC starting a class with background task that uses an injected service
I have a utility class that recieves emails with a background TimerTask that needs to invoke a method on one of my injected DAOs to store the messages in the db. How do I get this class to load when I start my app and make sure the injected services are set? With EagerLoad the class gets instantiated but of course the services are null. John
Re: Deadlock found while init IOC container.
That's an interesting find; I've never seen that before. Does it happen consistently? That being said, it's highly unlikely we can reproduce it without some insight into what modules you are using and (a guess from what I'm seeing in the stack trace) whats in your @Startup module methods. On Thu, Oct 10, 2013 at 12:14 AM, Jun Tsai wrote: > Found one Java-level deadlock: > = > "Tapestry PeriodicExecutor": > waiting for ownable synchronizer 0x0007569066f8, (a > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), > which is held by "main" > "main": > waiting to lock monitor 0x7fd8fc004188 (object 0x000756e7, a > org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator), > which is held by "Tapestry PeriodicExecutor" > > Java stack information for the threads listed above: > === > "Tapestry PeriodicExecutor": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x0007569066f8> (a > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) > at > > java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) > at > > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:941) > at > > java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1261) > at > > java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:594) > at > > org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:75) > at > > org.apache.tapestry5.ioc.internal.ModuleImpl.findOrCreate(ModuleImpl.java:213) > at > > org.apache.tapestry5.ioc.internal.ModuleImpl.getService(ModuleImpl.java:109) > at > > org.apache.tapestry5.ioc.internal.RegistryImpl.getService(RegistryImpl.java:421) > at > > org.apache.tapestry5.ioc.internal.RegistryImpl.getServiceByTypeAlone(RegistryImpl.java:670) > at > > org.apache.tapestry5.ioc.internal.RegistryImpl.getServiceByTypeAndMarkers(RegistryImpl.java:684) > at > > org.apache.tapestry5.ioc.internal.RegistryImpl.getService(RegistryImpl.java:643) > at > > org.apache.tapestry5.ioc.internal.TypeCoercerProxyImpl.delegate(TypeCoercerProxyImpl.java:39) > at > > org.apache.tapestry5.ioc.internal.TypeCoercerProxyImpl.coerce(TypeCoercerProxyImpl.java:49) > at > > org.apache.tapestry5.ioc.internal.ValidatingMappedConfigurationWrapper.add(ValidatingMappedConfigurationWrapper.java:82) > at super.H.b.a(LocalSuperSyncModule.scala:38) > at super.H.a.contributeApplicationDefaults(LocalSuperSyncModule.scala) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > > org.apache.tapestry5.ioc.internal.ContributionDefImpl.invokeMethod(ContributionDefImpl.java:120) > at > > org.apache.tapestry5.ioc.internal.ContributionDefImpl.contribute(ContributionDefImpl.java:86) > at > org.apache.tapestry5.ioc.internal.RegistryImpl$7.run(RegistryImpl.java:568) > at > > org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:51) > at > > org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:48) > at > > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74) > at > > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:47) > at > > org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.run(PerThreadOperationTracker.java:76) > at > > org.apache.tapestry5.ioc.internal.RegistryImpl.addToMappedConfiguration(RegistryImpl.java:564) > at > > org.apache.tapestry5.ioc.internal.RegistryImpl.getMappedConfiguration(RegistryImpl.java:518) > at > > org.apache.tapestry5.ioc.internal.ServiceResourcesImpl$3.invoke(ServiceResourcesImpl.java:126) > at > > org.apache.tapestry5.ioc.internal.ServiceResourcesImpl$3.invoke(ServiceResourcesImpl.java:123) > at > > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74) > at > > org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87) > at > > org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124) > at > > org.apache.tapestry5.ioc.internal.ServiceResourcesImpl.getMappedConfiguration(ServiceResourcesImpl.java:121) > at > > org.apache.tapestry5.ioc.internal.AbstractServiceCreator.getMappedConfiguration(AbstractServiceCreator.java:144) > at > > org.apache.tapestry5.ioc.internal.AbstractServiceCreator.access$300(AbstractServiceCreator.java:35) > at > > org.apache.tapestry5.ioc.internal.AbstractServiceCreator$1.findResource(Abs
Deadlock found while init IOC container.
Found one Java-level deadlock: = "Tapestry PeriodicExecutor": waiting for ownable synchronizer 0x0007569066f8, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), which is held by "main" "main": waiting to lock monitor 0x7fd8fc004188 (object 0x000756e7, a org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator), which is held by "Tapestry PeriodicExecutor" Java stack information for the threads listed above: === "Tapestry PeriodicExecutor": at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x0007569066f8> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:941) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1261) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:594) at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:75) at org.apache.tapestry5.ioc.internal.ModuleImpl.findOrCreate(ModuleImpl.java:213) at org.apache.tapestry5.ioc.internal.ModuleImpl.getService(ModuleImpl.java:109) at org.apache.tapestry5.ioc.internal.RegistryImpl.getService(RegistryImpl.java:421) at org.apache.tapestry5.ioc.internal.RegistryImpl.getServiceByTypeAlone(RegistryImpl.java:670) at org.apache.tapestry5.ioc.internal.RegistryImpl.getServiceByTypeAndMarkers(RegistryImpl.java:684) at org.apache.tapestry5.ioc.internal.RegistryImpl.getService(RegistryImpl.java:643) at org.apache.tapestry5.ioc.internal.TypeCoercerProxyImpl.delegate(TypeCoercerProxyImpl.java:39) at org.apache.tapestry5.ioc.internal.TypeCoercerProxyImpl.coerce(TypeCoercerProxyImpl.java:49) at org.apache.tapestry5.ioc.internal.ValidatingMappedConfigurationWrapper.add(ValidatingMappedConfigurationWrapper.java:82) at super.H.b.a(LocalSuperSyncModule.scala:38) at super.H.a.contributeApplicationDefaults(LocalSuperSyncModule.scala) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tapestry5.ioc.internal.ContributionDefImpl.invokeMethod(ContributionDefImpl.java:120) at org.apache.tapestry5.ioc.internal.ContributionDefImpl.contribute(ContributionDefImpl.java:86) at org.apache.tapestry5.ioc.internal.RegistryImpl$7.run(RegistryImpl.java:568) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:51) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl$1.invoke(OperationTrackerImpl.java:48) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:47) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.run(PerThreadOperationTracker.java:76) at org.apache.tapestry5.ioc.internal.RegistryImpl.addToMappedConfiguration(RegistryImpl.java:564) at org.apache.tapestry5.ioc.internal.RegistryImpl.getMappedConfiguration(RegistryImpl.java:518) at org.apache.tapestry5.ioc.internal.ServiceResourcesImpl$3.invoke(ServiceResourcesImpl.java:126) at org.apache.tapestry5.ioc.internal.ServiceResourcesImpl$3.invoke(ServiceResourcesImpl.java:123) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:74) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124) at org.apache.tapestry5.ioc.internal.ServiceResourcesImpl.getMappedConfiguration(ServiceResourcesImpl.java:121) at org.apache.tapestry5.ioc.internal.AbstractServiceCreator.getMappedConfiguration(AbstractServiceCreator.java:144) at org.apache.tapestry5.ioc.internal.AbstractServiceCreator.access$300(AbstractServiceCreator.java:35) at org.apache.tapestry5.ioc.internal.AbstractServiceCreator$1.findResource(AbstractServiceCreator.java:107) at org.apache.tapestry5.ioc.internal.util.DelegatingInjectionResources.findResource(DelegatingInjectionResources.java:38) at org.apache.tapestry5.ioc.internal.util.InternalUtils.calculateInjection(InternalUtils.java:231) at org.apache.tapestry5.ioc.internal.util.InternalUtils.access$000(InternalUtils.java:50) at org.apache.tapestry5.ioc.internal.util.InternalUtils$4.invoke(InternalUtils.java:289) at org.apache.tapestry5.ioc.internal.util.InternalUtils$4.invoke(InternalUtils.java:286) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTra
Re: T5 IOC Integration Questions
Norman, I implemented something I called Invoker lately. It was quite easy to do field injection and calling methods where you inject all parameters. The mixed part was quite difficult though (provide some parameters and inject the others). Also be aware of that the ordering of methods is not guaranteed in any way using JDK 7 192 and above (getDeclaredMethods and getMethods along with getConstructors now return methods in random order). I fixed the issue by using ASM and visit each method in the order they are stored within the class file (which is the exact order you define it in the java file). So beside this if you are doing invocation and injection on fields and methods go ahead. This wont take more then an hour at most. If you need additional help, just ask. You can even invoke and create private classes / constructors and methods which comes quite handy in case of writing test cases. Cheers, Martin (Kersten) 2013/9/27 Norman Franke > On Sep 27, 2013, at 1:31 PM, Thiago H de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > On Fri, 27 Sep 2013 13:11:33 -0300, Norman Franke > wrote: > > > >> I'm trying to better integrate Atmosphere and Tapestry 5. It would make > life easier if there was a way for T5's IOC layer to inject into an > existing object, instead of having it need to create objects itself. I > can't find one, if it exists. > > > > Unless there's some setter we could call through injection, I don't > think any other IoC does that (injecting stuff into already existing > objects). Most IoC features can only be implemented because the IoC > container is instantiating the object. > > > > -- > > Thiago H. de Paula Figueiredo > > > Spring does, as does Guice. You lose some things, but it's better than > nothing. > > Norman Franke > Answering Service for Directors, Inc. > www.myasd.com > > > >
Re: T5 IOC Integration Questions
On Sep 27, 2013, at 1:31 PM, Thiago H de Paula Figueiredo wrote: > On Fri, 27 Sep 2013 13:11:33 -0300, Norman Franke wrote: > >> I'm trying to better integrate Atmosphere and Tapestry 5. It would make life >> easier if there was a way for T5's IOC layer to inject into an existing >> object, instead of having it need to create objects itself. I can't find >> one, if it exists. > > Unless there's some setter we could call through injection, I don't think any > other IoC does that (injecting stuff into already existing objects). Most IoC > features can only be implemented because the IoC container is instantiating > the object. > > -- > Thiago H. de Paula Figueiredo Spring does, as does Guice. You lose some things, but it's better than nothing. Norman Franke Answering Service for Directors, Inc. www.myasd.com
Re: T5 IOC Integration Questions
On Fri, 27 Sep 2013 13:11:33 -0300, Norman Franke wrote: I'm trying to better integrate Atmosphere and Tapestry 5. It would make life easier if there was a way for T5's IOC layer to inject into an existing object, instead of having it need to create objects itself. I can't find one, if it exists. Unless there's some setter we could call through injection, I don't think any other IoC does that (injecting stuff into already existing objects). Most IoC features can only be implemented because the IoC container is instantiating the object. -- Thiago H. de Paula Figueiredo - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
T5 IOC Integration Questions
I'm trying to better integrate Atmosphere and Tapestry 5. It would make life easier if there was a way for T5's IOC layer to inject into an existing object, instead of having it need to create objects itself. I can't find one, if it exists. I have made a few modifications to Atmosphere that let me use the Tapestry IOC layer to create most objects, which allows me to use @Inject to gain access to my services from classes Atmosphere instantiates to process requests. I'd like to have a more complete solution where the Tapestry IOC layer can know about the AtmosphereFrameowrk and AtmosphereConfig and inject them as well. Any thoughts? Norman Franke Answering Service for Directors, Inc. www.myasd.com
