[
https://issues.apache.org/jira/browse/TAPESTRY-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536513
]
Dan Adams commented on TAPESTRY-1842:
-------------------------------------
The way I would l like to see this implemented is to read the final
configuration and create coercions for each specific entity type rather than
changing how coercions work. (I'm pretty much done with TAPESTRY-1576 and will
probably commit soon.) This means that you don't need entities to share an
interface (meaning it can be implemented in tapestry rather than our library)
and that the coerced string could be shorter. Since the coercion knows the
concrete entity type you could just use something like "entity:42" rather than
"entity:com.example.app.entities.Widget:42".
But as Davor pointed out, waiting for the final Hibernate configuration may be
way too far out for adding something as central as coercions. The actual error
I'm getting (at the bottom of the stack) is:
Caused by: java.lang.IllegalStateException: Construction of service 'Alias' has
failed due to recursion: the service depends on itself in some way. Please
check org.apache.tapestry.services.TapestryModule.build(Logger, String,
AliasManager, Collection) (at TapestryModule.java:252) for references to
another service that is itself dependent on service 'Alias'.
at
org.apache.tapestry.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject(RecursiveServiceCreationCheckWrapper.java:53)
at
org.apache.tapestry.ioc.internal.services.JustInTimeObjectCreator.createObject(JustInTimeObjectCreator.java:61)
... 86 more
This happened when trying to inject the HibernateSessionSource into the
contribution method. I had the same problem with trying to inject the Session.
I was able to get around the problem with Session by using ServiceBinder in a
bind() method and having the services injected in the constructor but this
won't work with getting the final configuration because you need to add a
CoercionTuple for each entity (two for each actually).
> Allow coercions to handle multiple or non-concrete types
> --------------------------------------------------------
>
> Key: TAPESTRY-1842
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1842
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-ioc
> Affects Versions: 5.0.6
> Reporter: Dan Adams
> Priority: Critical
>
> I was working on implementing something similar to TAPESTRY-1653 and ran into
> a problem. In our system, all hibernate entities implement an interface. I
> wanted to create a coercion that would handle going from String -> entity and
> from entity -> String. The problem with this was that, with the way coercion
> currently works, you have to add coercions for every concrete enttiy type
> rather than having one coercion that knows how to load any entity from the
> Session by id. This introduces a chicken-and-egg problem where in the
> coercion depends on the Hibernation Configuration being created already. This
> causes IoC to kick out because there is a dependency loop. Either I need to
> find a way around the dependency loop (which I can't see how) and register
> coercions for each specific entity type at start-up or register one coercion
> for all entities.
> Obviously this introduces some complications with the coercion logic but it
> appears to be very much a necessary ability. I'm not opposed to implementing
> it others can chime in if they have opinions about this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
