Thanks guys this has been a very big piece of tapestry I never really
understood.
On Thursday, May 10, 2012, Howard Lewis Ship [via Tapestry] wrote:
> Historically, constructor injection came first; direct field injection
> (which uses reflection) came laster, in part because of student in one
>
Historically, constructor injection came first; direct field injection
(which uses reflection) came laster, in part because of student in one
of my workshops pointed out the inconsistency.
I generally prefer constructor injection as well, since the field can
then be marked "final". That gives me
Keep in mind that you don't need to use @Inject in your services. Tapestry
will use the constructor with the most arguments and will pass values
matched by type (and annotations) from the registry.
I prefer the constructor injection to private field injection as I can test
my services without need
On Thu, 10 May 2012 14:04:17 -0300, George Christman
wrote:
Thanks guys, I wasn't aware we could use tapestry inject outside of
pages and components.
Tapestry-IoC (which is independent of Tapestry-Core, which is the web
framework) is able to inject services into any object created by
T
Thanks guys, I wasn't aware we could use tapestry inject outside of pages and
components.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Using-generics-in-tapestry-service-tp5700399p5700938.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
--
Due to type erasure, Tapestry doesn't see the generics when using
ServiceBinder.bind(), and that's the preferred way to define services
now (there's almost no need at this point to use service builder
methods, except for rare cases where the the service implementation is
generated on the fly).
I
Use either
@InjectService("serviceId")
private MyService myService;
or
@ServiceId("serviceId")
@Inject
private MyService myService;
Sent from my iPhone
On May 10, 2012, at 10:10 PM, George Christman wrote:
> Well It worked for a single service implementing the interface, as soon as I
> ad
Well It worked for a single service implementing the interface, as soon as I
added a second service it blew up :(
I was given this exception
Caused by: java.lang.RuntimeException: Error building service proxy for
service 'Scheduler' (at
org.mydomain.eprs.services.Scheduler(HibernateSessionSource,
Thanks guys, I figured it out. I completely missed the "build" in your
example. Anyhow works like a charm. Thanks.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Using-generics-in-tapestry-service-tp5700399p5700785.html
Sent from the Tapestry - User mailing list archive a
This is my real world code, I'm just confused with the service id despite
reading the docs over and over.
public static void bind(ServiceBinder binder) {
binder.bind(UserInfo.class, UserInfoImpl.class);
binder.bind(AutocompleteCache.class, AutocompleteCacheImpl.class);
Tapestry has naming conventions in the AppModule and "build" methods must
start with the word "build" (or use equivelant annotations).
You haven't shown me your code but it looks like your method is called
"userDoSomethingClass()". If you take a look at the code I gave you, the
method is called "b
Lance anychance you could provide me with a sample of the build method? I
seen this in the Tap docs, just doesn't make total sense to me.
package org.example.myapp.services;
public class MyAppModule
{
public static Indexer build()
{
return new IndexerImpl();
}
}
--
View this message
To differentiate between services you can either use different annotations or
different service ids.
For annotations read "Disambiguation with Marker Annotations" under
http://tapestry.apache.org/defining-tapestry-ioc-services.html
For serviceIds read "Service Ids" under the same link
regards
You need to call the method "build" where is the name
of the service.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Using-generics-in-tapestry-service-tp5700399p5700637.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
2012-05-10 11:24:04.649:WARN::failed app: java.lang.RuntimeException: Module
class org.mydomain.eprs.services.AppModule contains unrecognized public
methods: public org.mydomain.eprs.services.DoSomethingClass
org.mydomain.eprs.services.AppModule.userDoSomethingClass().
2012-05-10 11:24:04.649:WARN:
Can you paste the code and the entire error message (I get the feeling
there's more to the message).
This page explains using service id's or annotations to differentiate
services with the same interface
http://tapestry.apache.org/defining-tapestry-ioc-services.html
--
View this message in contex
When I placed your code snippet in the app module, it gave me the following
exception
contains unrecognized public methods: public
org.mydomain.eprs.services.doSomethingClass
I guess if this isn't possible, I'll just have to do this a different way. I
at least wanted to try your suggestion first
I can't say that I've used generic services before. I was assuming that under
the hood, Tapestry would think that there were two instances of the same
interface (due to type erasure). I have provided you with a way of dealing
with two services of the same interface. Tapestry also supports custom
ma
That would be great Taha.
Lance, I'm assuming your suggestion is a work around to what Taha just
recently stated. Would I still need to provide bindings for either
buildUserDoSomethingClass or my doSomethingClass's?
Thanks, George
--
View this message in context:
http://tapestry.1045711.n5.nab
Hello
Unfortunately generics are not supported by Tapestry Services. ASM 4, to which
Plastic will be upgraded to soon, has support for Generics
(http://weblogs.java.net/blog/forax/archive/2011/04/17/asm-4-rc1-released) so
hopefully it might be in the coming version.
regards
Taha
On May 10, 20
You would probably want to do it like this:
AppModule.java
---
public DoSomethingClass buildUserDoSomethingClass() {
return new DoSomethingClassImpl();
}
public DoSomethingClass buildDateDoSomethingClass() {
return new DoSomethingClassImpl();
}
Page.java
-
@Inject @Name
21 matches
Mail list logo