[Hibernate-JIRA] Created: (HHH-7319) ServiceContributingIntegrator do not have access to the configuration and cannot adjust service registration accordingly
5:27 a.m.
ServiceContributingIntegrator do not have access to the configuration and cannot adjust
service registration accordingly
------------------------------------------------------------------------------------------------------------------------
Key: HHH-7319
URL: https://hibernate.onjira.com/browse/HHH-7319
Project: Hibernate ORM
Issue Type: Improvement
Reporter: Emmanuel Bernard
In Hibernate OGM, I don't want to set my custom service initiators unless I know it is
explicitly being used.
I cannot do that today because ServiceContributingIntegrator does not have access to the
configuration.
I had to write all my service initiators so that they look at the configuration and
delegate to the "default" service initiator. That's a lot of redundant code.
I wonder if we can do better.
See
https://github.com/hibernate/hibernate-ogm/blob/master/hibernate-ogm-core...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:35 a.m.
New subject: [Hibernate-JIRA] Issue Comment Edited: (HHH-7319) ServiceContributingIntegrator do not have access to the configuration and cannot adjust service registration accordingly
[
https://hibernate.onjira.com/browse/HHH-7319?page=com.atlassian.jira.plug...
]
Steve Ebersole edited comment on HHH-7319 at 5/14/12 10:34 AM:
---------------------------------------------------------------
Do we want each {{Integrator}} to be responsible for enabled/disabled checking (which is
how this is done today)? Or do we look at more centralized way to let the {{Integrator}}
tell ORM whether it is enabled/disabled?
{code:title=Integrator.java|borderStyle=solid}
public interface Integrator {
/**
* Determine whether this Integrator should be considered enabled. Implication of
{@code false}
* is that the Integrator will be skipped in all "integration and disintegration
activities"
*/
public boolean isEnabled(Map<?,?> settings);
...
}
{code}
(totally a guess at the signature)
was (Author: steve):
Do we want each {{Integrator}} to be responsible for enabled/disabled checking (which
is how this is done today)? Or do we look at more centralized way to let the
{{Integrator}} tell ORM whether it is enabled/disabled?
{code:Integrator.java|borderStyle=solid}
public interface Integrator {
/**
* Determine whether this Integrator should be considered enabled. Implication of
{@code false}
* is that the Integrator will be skipped in all "integration and disintegration
activities"
*/
public boolean isEnabled(Map<?,?> settings);
...
}
{code}
(totally a guess at the signature)
ServiceContributingIntegrator do not have access to the configuration
and cannot adjust service registration accordingly
------------------------------------------------------------------------------------------------------------------------
Key: HHH-7319
URL: https://hibernate.onjira.com/browse/HHH-7319
Project: Hibernate ORM
Issue Type: Improvement
Reporter: Emmanuel Bernard
In Hibernate OGM, I don't want to set my custom service initiators unless I know it
is explicitly being used.
I cannot do that today because ServiceContributingIntegrator does not have access to the
configuration.
I had to write all my service initiators so that they look at the configuration and
delegate to the "default" service initiator. That's a lot of redundant code.
I wonder if we can do better.
See
https://github.com/hibernate/hibernate-ogm/blob/master/hibernate-ogm-core...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:35 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-7319) ServiceContributingIntegrator do not have access to the configuration and cannot adjust service registration accordingly
[
https://hibernate.onjira.com/browse/HHH-7319?page=com.atlassian.jira.plug...
]
Steve Ebersole commented on HHH-7319:
-------------------------------------
Do we want each {{Integrator}} to be responsible for enabled/disabled checking (which is
how this is done today)? Or do we look at more centralized way to let the {{Integrator}}
tell ORM whether it is enabled/disabled?
{code:Integrator.java|borderStyle=solid}
public interface Integrator {
/**
* Determine whether this Integrator should be considered enabled. Implication of
{@code false}
* is that the Integrator will be skipped in all "integration and disintegration
activities"
*/
public boolean isEnabled(Map<?,?> settings);
...
}
{code}
(totally a guess at the signature)
ServiceContributingIntegrator do not have access to the configuration
and cannot adjust service registration accordingly
------------------------------------------------------------------------------------------------------------------------
Key: HHH-7319
URL: https://hibernate.onjira.com/browse/HHH-7319
Project: Hibernate ORM
Issue Type: Improvement
Reporter: Emmanuel Bernard
In Hibernate OGM, I don't want to set my custom service initiators unless I know it
is explicitly being used.
I cannot do that today because ServiceContributingIntegrator does not have access to the
configuration.
I had to write all my service initiators so that they look at the configuration and
delegate to the "default" service initiator. That's a lot of redundant code.
I wonder if we can do better.
See
https://github.com/hibernate/hibernate-ogm/blob/master/hibernate-ogm-core...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:40 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-7319) ServiceContributingIntegrator do not have access to the configuration and cannot adjust service registration accordingly
[
https://hibernate.onjira.com/browse/HHH-7319?page=com.atlassian.jira.plug...
]
Emmanuel Bernard commented on HHH-7319:
---------------------------------------
Good question. I am fine with the isEnabled approach even though a more generic configure
approach would give the Integrator more flexibility. Playing the other side, if configure
becomes too complex, that's stepping into what service initiator can do and isolate.
ServiceContributingIntegrator do not have access to the configuration
and cannot adjust service registration accordingly
------------------------------------------------------------------------------------------------------------------------
Key: HHH-7319
URL: https://hibernate.onjira.com/browse/HHH-7319
Project: Hibernate ORM
Issue Type: Improvement
Reporter: Emmanuel Bernard
In Hibernate OGM, I don't want to set my custom service initiators unless I know it
is explicitly being used.
I cannot do that today because ServiceContributingIntegrator does not have access to the
configuration.
I had to write all my service initiators so that they look at the configuration and
delegate to the "default" service initiator. That's a lot of redundant code.
I wonder if we can do better.
See
https://github.com/hibernate/hibernate-ogm/blob/master/hibernate-ogm-core...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:56 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-7319) ServiceContributingIntegrator do not have access to the configuration and cannot adjust service registration accordingly
[
https://hibernate.onjira.com/browse/HHH-7319?page=com.atlassian.jira.plug...
]
Steve Ebersole commented on HHH-7319:
-------------------------------------
Not really sure what you are saying with your last sentence there...
There really are not complex cases here. At least that I do not see. If there, lets
document them. To me, the only real complicated cases are things like validation and
envers where the integration maybe be enabled, but we find no specific annotations.
Ideally it would be great to disable the integrations completely in those cases. However
something you have to watch out for is thinking that you can dynamically change services
after the registry is built. My initial proxy-based approach was developed exactly for
this case of allowing dynamic remapping of the role (interface) to service instance. But
that introduced quite a bit of concurrent contention so we ripped that out. The end game
being that once services are defined, they are set.
My concern is specifically having multiple implicit notions of whether the integrator is
enabled/disabled. So in {{OgmIntegrator}} you'd have 3 such implicit enabled/disabled
checks: once for integrate, once for disintegrate, and once for prepareServices. So how
does the Integrator implementation keep enabled/disabled consistent across all 3 of those
calls?
ServiceContributingIntegrator do not have access to the configuration
and cannot adjust service registration accordingly
------------------------------------------------------------------------------------------------------------------------
Key: HHH-7319
URL: https://hibernate.onjira.com/browse/HHH-7319
Project: Hibernate ORM
Issue Type: Improvement
Reporter: Emmanuel Bernard
In Hibernate OGM, I don't want to set my custom service initiators unless I know it
is explicitly being used.
I cannot do that today because ServiceContributingIntegrator does not have access to the
configuration.
I had to write all my service initiators so that they look at the configuration and
delegate to the "default" service initiator. That's a lot of redundant code.
I wonder if we can do better.
See
https://github.com/hibernate/hibernate-ogm/blob/master/hibernate-ogm-core...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5075
days inactive
5077
days old
hibernate-issues@lists.jboss.org
4 comments
2 participants
participants (2)
-
Emmanuel Bernard (JIRA) -
Steve Ebersole (JIRA)