Discussion:
svn commit: r1819127 - in /turbine/core/trunk: ./ src/java/org/apache/turbine/modules/actions/ src/java/org/apache/turbine/om/security/ src/java/org/apache/turbine/services/ src/java/org/apache/turbine/services/security/ src/java/org/apache/turbine/util/
Thomas Vandahl
2017-12-24 11:21:42 UTC
Permalink
Author: gk
Date: Sat Dec 23 09:32:08 2017
New Revision: 1819127
URL: http://svn.apache.org/viewvc?rev=1819127&view=rev
- updates due to fulcrum security version 1.1.2-SNAPSHOT
- allow annotations in turbine services (TODO test)
[...]
Modified: turbine/core/trunk/src/java/org/apache/turbine/services/BaseServiceBroker.java
URL: http://svn.apache.org/viewvc/turbine/core/trunk/src/java/org/apache/turbine/services/BaseServiceBroker.java?rev=1819127&r1=1819126&r2=1819127&view=diff
==============================================================================
--- turbine/core/trunk/src/java/org/apache/turbine/services/BaseServiceBroker.java (original)
+++ turbine/core/trunk/src/java/org/apache/turbine/services/BaseServiceBroker.java Sat Dec 23 09:32:08 2017
@@ -33,6 +33,8 @@ import org.apache.commons.configuration.
import org.apache.commons.lang.StringUtils;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+import org.apache.turbine.annotation.AnnotationProcessor;
+import org.apache.turbine.util.TurbineException;
/**
* A generic implementation of a <code>ServiceBroker</code> which
@@ -373,6 +375,16 @@ public abstract class BaseServiceBroker
if (!instance.getInit())
{
+
+ try
+ {
+ // convenience annotation in Turbine services
+ AnnotationProcessor.process(instance);
+ }
+ catch ( TurbineException e )
+ {
+ throw new InstantiationException( e.getMessage(), e );
+ }
// this call might result in an indirect recursion
instance.init();
}
I'm afraid this will cause a stack overflow if you happen to hit a
cyclic dependency. The AnnotationProcessor expects services to be
initialized so I left this out intentionally.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org
Georg Kallidis
2018-01-04 15:45:50 UTC
Permalink
I thought as injectTurbineService just calls getService - which may be
called at any time later - we should be quite safe (?).

But even if processing is done after the init call it is only the early
initialized services, which gets annotated and injections of other
services would remain indeed unresolved. I think, if we use hashset, which
gets updated for each injected service (name) this could be fixed (running
the annotations process recursively after the service init loop). Injected
Turbine service annotation could then be used in all methods, but not in
the init method itself and would require at least one early initialized
root service.

I think about this once more, waiting for some response...

Best regards, Georg



Von: Thomas Vandahl <***@apache.org>
An: ***@turbine.apache.org
Datum: 24.12.2017 12:21
Betreff: Re: svn commit: r1819127 - in /turbine/core/trunk: ./
src/java/org/apache/turbine/modules/actions/
src/java/org/apache/turbine/om/security/
src/java/org/apache/turbine/services/
src/java/org/apache/turbine/services/security/
src/java/org/apache/turbine/util/
Author: gk
Date: Sat Dec 23 09:32:08 2017
New Revision: 1819127
URL: http://svn.apache.org/viewvc?rev=1819127&view=rev
- updates due to fulcrum security version 1.1.2-SNAPSHOT
- allow annotations in turbine services (TODO test)
[...]
turbine/core/trunk/src/java/org/apache/turbine/services/BaseServiceBroker.java
http://svn.apache.org/viewvc/turbine/core/trunk/src/java/org/apache/turbine/services/BaseServiceBroker.java?rev=1819127&r1=1819126&r2=1819127&view=diff
==============================================================================
---
turbine/core/trunk/src/java/org/apache/turbine/services/BaseServiceBroker.java
(original)
+++
turbine/core/trunk/src/java/org/apache/turbine/services/BaseServiceBroker.java
Sat Dec 23 09:32:08 2017
@@ -33,6 +33,8 @@ import org.apache.commons.configuration.
import org.apache.commons.lang.StringUtils;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+import org.apache.turbine.annotation.AnnotationProcessor;
+import org.apache.turbine.util.TurbineException;
/**
* A generic implementation of a <code>ServiceBroker</code> which
@@ -373,6 +375,16 @@ public abstract class BaseServiceBroker
if (!instance.getInit())
{
+
+ try
+ {
+ // convenience annotation in Turbine services
+ AnnotationProcessor.process(instance);
+ }
+ catch ( TurbineException e )
+ {
+ throw new InstantiationException( e.getMessage(), e );
+ }
// this call might result in an indirect recursion
instance.init();
}
I'm afraid this will cause a stack overflow if you happen to hit a
cyclic dependency. The AnnotationProcessor expects services to be
initialized so I left this out intentionally.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org
Thomas Vandahl
2018-01-04 17:41:15 UTC
Permalink
Post by Georg Kallidis
I thought as injectTurbineService just calls getService - which may be
called at any time later - we should be quite safe (?).
Yes, but getService initializes the service if not yet done so you may
end up in a endless recursion.
Post by Georg Kallidis
But even if processing is done after the init call it is only the early
initialized services, which gets annotated and injections of other
services would remain indeed unresolved. I think, if we use hashset, which
gets updated for each injected service (name) this could be fixed (running
the annotations process recursively after the service init loop). Injected
Turbine service annotation could then be used in all methods, but not in
the init method itself and would require at least one early initialized
root service.
Please keep in mind that the Turbine service layer can be extended by
other service providers, which would make this tracking next to
impossible. I already had a hard time to resolve the automatic
early-init of service provider classes. I'd rather go without this feature.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org
Georg Kallidis
2018-01-05 08:58:09 UTC
Permalink
ok, I reverted the (anyway still incomplete) service annotation
processing. To illustrate, what I intended, a patch is included. It may be
still incomplete or incorrect, but I think it would be possible at the
end.

Best regards, Georg





Von: Thomas Vandahl <***@apache.org>
An: Turbine Developers List <***@turbine.apache.org>
Datum: 04.01.2018 18:41
Betreff: Re: svn commit: r1819127 - in /turbine/core/trunk: ./
src/java/org/apache/turbine/modules/actions/
src/java/org/apache/turbine/om/security/
src/java/org/apache/turbine/services/
src/java/org/apache/turbine/services/security/
src/java/org/apache/turbine/util/
Post by Georg Kallidis
I thought as injectTurbineService just calls getService - which may be
called at any time later - we should be quite safe (?).
Yes, but getService initializes the service if not yet done so you may
end up in a endless recursion.
Post by Georg Kallidis
But even if processing is done after the init call it is only the early
initialized services, which gets annotated and injections of other
services would remain indeed unresolved. I think, if we use hashset, which
gets updated for each injected service (name) this could be fixed (running
the annotations process recursively after the service init loop). Injected
Turbine service annotation could then be used in all methods, but not in
the init method itself and would require at least one early initialized
root service.
Please keep in mind that the Turbine service layer can be extended by
other service providers, which would make this tracking next to
impossible. I already had a hard time to resolve the automatic
early-init of service provider classes. I'd rather go without this
feature.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-***@turbine.apache.org
For additional commands, e-mail: dev-***@turbine.apache.org

Loading...