Hi,
thank you for your time, but I still have more questions...
e) Are the [...]Module classes to be placed in the services package in the
Tapestry app module?
f) Is the naming important? Or could I have a FooModule class without having a
Foo module?
And another topic has arisen, which leads me back to b):
b.2) I've had the persistence.xml placed in the dao-hibernate module,
under src/main/java/META-INF/persistence.xml.
When I started the application and want to fill the database, no entity manager
can be found.
Error: " Unable to locate a single EntityManager. You must provide the
persistence unit name as defined in the persistence.xml using the
@PersistenceContext annotation."
I only have one persistence unit defined: "appUnit".
Each of my DAO classes is basically doing this:
@PersistenceContext(unitName="appUnit")
private EntityManager em;
public GlobalDAOImpl(final EntityManager newEm) {
this.em = newEm;
}
Am I doing something wrong here? Or should the persistence.xml be in a
different place?
Regards,
Daniel P.
-----Ursprüngliche Nachricht-----
Von: Charlouze [mailto:[email protected]]
Gesendet: Donnerstag, 23. April 2015 13:22
An: Tapestry users
Betreff: Re: AW: AW: Splitting a tapestry web app into modules
Yep it's correct and no, there isn't any order.
Each of your modules should have its own ModuleNameModule class. This class
should contain a "public static void bind(ServiceBinder binder)" method where
services are bound to the tapestry registry.
An implementation of service should have a constructor where parameters are
other services you want to inject in order to use them (and optionally the
contribution parameter).
Le jeu. 23 avr. 2015 à 12:08, Poggenpohl, Daniel <
[email protected]> a écrit :
> Hi again,
>
> so how flexible is this? I'm currently thinking about adding the
> tapestry-annotations dependency to my controller who needs to @Inject
> the DAOs. But if the DAOs themselves are declared as services, then I
> could add the necessary DAO interfaces to my controller constructor as
> parameters and also wouldn't need to @Inject them, if I understand you.
>
> Is this correct? And is there a specific order that the services must
> be added to the binder?
>
> Regards,
> Daniel P.
>
> -----Ursprüngliche Nachricht-----
> Von: Charlouze [mailto:[email protected]]
> Gesendet: Donnerstag, 23. April 2015 11:54
> An: Tapestry users
> Betreff: Re: AW: AW: Splitting a tapestry web app into modules
>
> If your service is bound to the registry via a ServiceBinder then it
> should.
>
> Le jeu. 23 avr. 2015 à 11:50, Poggenpohl, Daniel <
> [email protected]> a écrit :
>
> > Hi,
> >
> > do you mean that if I add an EntityManager as a parameter to my
> > service constructor, the appropriate EntityManager is inserted as a
> > parameter value by Tapestry? Like in other methods in AppModule that
> > I
> read about?
> >
> > Regards,
> > Daniel P.
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Charlouze [mailto:[email protected]]
> > Gesendet: Donnerstag, 23. April 2015 11:37
> > An: Tapestry users
> > Betreff: Re: AW: AW: Splitting a tapestry web app into modules
> >
> > Hey !
> >
> > You can define your DAO as service and get any other services you
> > need in your DAO by adding parameters to your DAO constructor.
> >
> > Le jeu. 23 avr. 2015 à 11:23, Poggenpohl, Daniel <
> > [email protected]> a écrit :
> >
> > > Hi everyone,
> > >
> > > thank you for adressing my questions, I think that helped me to
> > > accomplish my goal.
> > >
> > > One more question for the moment:
> > > d) My dao-hibernate module, the DAO implementation module using
> > > hibernate as a persistence provider...
> > > Previously, in my single module project, I would have the DAO
> > > implementation running as a service in Tapestry. Doing it that
> > > way, I could @Inject the appropriate EntityManager.
> > > I know I can still run the DAOs as services in Tapestry if I add
> > > them in AppModule.
> > > But how do I receive the appropriate EntityManager without @Inject?
> > > Is there another simple way or do I have to manually create the
> > EntityManager?
> > >
> > > (I know that I can add a dependency to tapestry5-annotations)
> > >
> > > Regards,
> > > Daniel P.
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Charlouze [mailto:[email protected]]
> > > Gesendet: Mittwoch, 22. April 2015 16:59
> > > An: Tapestry users
> > > Betreff: Re: AW: AW: Splitting a tapestry web app into modules
> > >
> > > hey !
> > >
> > > here is my thoughts about your concerns :
> > >
> > > a) controllers should be services that are bound to the registry
> > > in a ControllerModule class.
> > >
> > > b) persistence.xml file should probably be in your dao-hibernate
> module.
> > > You can configure where to find this file in a Module class.
> > >
> > > c) thiago already answer this one :D
> > >
> > > Cheers,
> > > Charles
> > >
> > > Le mer. 22 avr. 2015 à 16:43, Thiago H de Paula Figueiredo <
> > > [email protected]> a écrit :
> > >
> > > > On Wed, 22 Apr 2015 10:53:01 -0300, Poggenpohl, Daniel
> > > > <[email protected]> wrote:
> > > >
> > > > > Hello,
> > > >
> > > > Hi!
> > > >
> > > > > First, to be generic with my DAO interfaces, I can't use
> > > > > @CommitAfter on them, because then I'd need a dependency to
> > > tapestry-jpa.
> > > >
> > > > If you use 5.4-beta-22 or up, you don't need to put the
> > > > annotation in the interface anymore: you can put it on the
> > > > service (in your case,
> > > > DAO) implementation. Problem solved! :D
> > > >
> > > > If you're not using 5.4-beta-22 or up, you can come up with your
> > > > own annotation and adapt the tapestry-jpa class which does the
> > > > service decoration or advice, JpaTransactionAdvisor, then add
> > > > this in module
> > > class:
> > > >
> > > > @Match("*DAO")
> > > > public static void adviseTransactionally(
> > > > YourJpaTransactionAdvisor advisor,
> > > > MethodAdviceReceiver receiver) {
> > > >
> > > > advisor.addTransactionCommitAdvice(receiver);
> > > > }
> > > >
> > > > --
> > > > Thiago H. de Paula Figueiredo
> > > > Tapestry, Java and Hibernate consultant and developer
> > > > http://machina.com.br
> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: [email protected]
> > > > For additional commands, e-mail: [email protected]
> > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
