Camel re-animation status

[Martin Krasser]

Hi,

I started to fix akka-camel errors after the 2.0 upgrade. Here's a
status update:

DONE: fixed compile errors and failing tests in akka-camel
TODO: rename id to address in Camel 'actor' component
TODO: update akka-camel-typed to new typed actor impl
TODO: merge akka-camel-typed back into akka-camel (no need to have a
separate module any more after re-impl of typed actor)
TODO: check if akka-camel is 'cluster-friendly'. I still need to take a
look at the new akka-cluster stuff but goal is that consumer and
producer actors can be clustered as well.

Anything I forgot?

Cheers,
Martin

--
Martin Krasser

blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

[Jonas Bonér]

Great. Thanks.

--

Jonas Bonér
CTO 

Typesafe - Enterprise-Grade Scala from the Experts

Phone: +46 733 777 123

Twitter: @jboner

[√iktor Ҡlang]

On Mon, May 23, 2011 at 12:15 PM, Martin Krasser <kras...@googlemail.com> wrote:

Hi,

I started to fix akka-camel errors after the 2.0 upgrade. Here's a status update:

DONE: fixed compile errors and failing tests in akka-camel
TODO: rename id to address in Camel 'actor' component
TODO: update akka-camel-typed to new typed actor impl
TODO: merge akka-camel-typed back into akka-camel (no need to have a separate module any more after re-impl of typed actor)
TODO: check if akka-camel is 'cluster-friendly'. I still need to take a look at the new akka-cluster stuff but goal is that consumer and producer actors can be clustered as well.

Anything I forgot?

Please give me feedback on the TypedActor stuff when you get to that, if there's something missing we can get that sorted.

Thanks,
√
 

Cheers,
Martin

--
Martin Krasser

blog:    http://krasserm.blogspot.com
code:    http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

--
Viktor Klang

Akka Tech Lead

Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

[Martin Krasser]

Am 23.05.11 13:16, schrieb √iktor Ҡlang:

On Mon, May 23, 2011 at 12:15 PM, Martin Krasser <kras...@googlemail.com> wrote:

Hi,

I started to fix akka-camel errors after the 2.0 upgrade. Here's a status update:

DONE: fixed compile errors and failing tests in akka-camel
TODO: rename id to address in Camel 'actor' component
TODO: update akka-camel-typed to new typed actor impl
TODO: merge akka-camel-typed back into akka-camel (no need to have a separate module any more after re-impl of typed actor)
TODO: check if akka-camel is 'cluster-friendly'. I still need to take a look at the new akka-cluster stuff but goal is that consumer and producer actors can be clustered as well.

Anything I forgot?

Please give me feedback on the TypedActor stuff when you get to that, if there's something missing we can get that sorted.

Will do but I'm not sure if I can get to it this week. Next week should be fine.

[Martin Krasser]

Am 23.05.11 13:16, schrieb √iktor Ҡlang:

On Mon, May 23, 2011 at 12:15 PM, Martin Krasser <kras...@googlemail.com> wrote:

Hi,

I started to fix akka-camel errors after the 2.0 upgrade. Here's a status update:

DONE: fixed compile errors and failing tests in akka-camel
TODO: rename id to address in Camel 'actor' component
TODO: update akka-camel-typed to new typed actor impl
TODO: merge akka-camel-typed back into akka-camel (no need to have a separate module any more after re-impl of typed actor)
TODO: check if akka-camel is 'cluster-friendly'. I still need to take a look at the new akka-cluster stuff but goal is that consumer and producer actors can be clustered as well.

Anything I forgot?

Please give me feedback on the TypedActor stuff when you get to that, if there's something missing we can get that sorted.

After some initial experiments to get akka-camel-typed working, I found that method/param annotations on the interface-class are not visible through the proxy object via reflection. (The methods themselves are visible, of course). This prevents

- the current akka-camel-typed code from processing @consume annotations
- Camel from processing bean-binding annotations such as @Header, @Body etc.

With the former AspectWerkz proxies, annotations were visible. I didn't have time so far to make further investigations here (and can only do that next week).

Any ideas how to do annotation processing when using JDK dynamic proxies? Maybe I just miss a simple solution ... or do we need a CGLIB based approach? ...

Thanks,
Martin

[Jonas Bonér]

This is a blocker, needs to be fixed. 

--

Jonas Bonér
CTO 

Typesafe - Enterprise-Grade Scala from the Experts

Phone: +46 733 777 123

Twitter: @jboner

[√iktor Ҡlang]

On Tue, May 24, 2011 at 7:23 AM, Martin Krasser <kras...@googlemail.com> wrote:

Am 23.05.11 13:16, schrieb √iktor Ҡlang:

On Mon, May 23, 2011 at 12:15 PM, Martin Krasser <kras...@googlemail.com> wrote:

Hi,

I started to fix akka-camel errors after the 2.0 upgrade. Here's a status update:

DONE: fixed compile errors and failing tests in akka-camel
TODO: rename id to address in Camel 'actor' component
TODO: update akka-camel-typed to new typed actor impl
TODO: merge akka-camel-typed back into akka-camel (no need to have a separate module any more after re-impl of typed actor)
TODO: check if akka-camel is 'cluster-friendly'. I still need to take a look at the new akka-cluster stuff but goal is that consumer and producer actors can be clustered as well.

Anything I forgot?

Please give me feedback on the TypedActor stuff when you get to that, if there's something missing we can get that sorted.

After some initial experiments to get akka-camel-typed working, I found that method/param annotations on the interface-class are not visible through the proxy object via reflection. (The methods themselves are visible, of course). This prevents

- the current akka-camel-typed code from processing @consume annotations
- Camel from processing bean-binding annotations such as @Header, @Body etc.

With the former AspectWerkz proxies, annotations were visible. I didn't have time so far to make further investigations here (and can only do that next week).

Crap. Crap. Crap. Crap.

Annotations are the Devil™
 
Dynamic Proxy doesn't preserve the full signature of the class? I am shocked and saddened.

I want us to try to solve this without going back to loadtime/runtime weaving.

Any ideas?

[√iktor Ҡlang]

2011/5/24 √iktor Ҡlang <viktor...@gmail.com>

On Tue, May 24, 2011 at 7:23 AM, Martin Krasser <kras...@googlemail.com> wrote:

Am 23.05.11 13:16, schrieb √iktor Ҡlang:

On Mon, May 23, 2011 at 12:15 PM, Martin Krasser <kras...@googlemail.com> wrote:

Hi,

I started to fix akka-camel errors after the 2.0 upgrade. Here's a status update:

DONE: fixed compile errors and failing tests in akka-camel
TODO: rename id to address in Camel 'actor' component
TODO: update akka-camel-typed to new typed actor impl
TODO: merge akka-camel-typed back into akka-camel (no need to have a separate module any more after re-impl of typed actor)
TODO: check if akka-camel is 'cluster-friendly'. I still need to take a look at the new akka-cluster stuff but goal is that consumer and producer actors can be clustered as well.

Anything I forgot?

Please give me feedback on the TypedActor stuff when you get to that, if there's something missing we can get that sorted.

After some initial experiments to get akka-camel-typed working, I found that method/param annotations on the interface-class are not visible through the proxy object via reflection. (The methods themselves are visible, of course). This prevents

- the current akka-camel-typed code from processing @consume annotations
- Camel from processing bean-binding annotations such as @Header, @Body etc.

With the former AspectWerkz proxies, annotations were visible. I didn't have time so far to make further investigations here (and can only do that next week).

Crap. Crap. Crap. Crap.

Annotations are the Devil™
 
Dynamic Proxy doesn't preserve the full signature of the class? I am shocked and saddened.

I want us to try to solve this without going back to loadtime/runtime weaving.

Any ideas?

Would it help at all if I could provide a way to get at either the impl or the classes used for the interface, so you can pull the annotations from there?
 

[√iktor Ҡlang]

2011/5/24 √iktor Ҡlang <viktor...@gmail.com>

2011/5/24 √iktor Ҡlang <viktor...@gmail.com>

On Tue, May 24, 2011 at 7:23 AM, Martin Krasser <kras...@googlemail.com> wrote:

Am 23.05.11 13:16, schrieb √iktor Ҡlang:

On Mon, May 23, 2011 at 12:15 PM, Martin Krasser <kras...@googlemail.com> wrote:

Hi,

I started to fix akka-camel errors after the 2.0 upgrade. Here's a status update:

DONE: fixed compile errors and failing tests in akka-camel
TODO: rename id to address in Camel 'actor' component
TODO: update akka-camel-typed to new typed actor impl
TODO: merge akka-camel-typed back into akka-camel (no need to have a separate module any more after re-impl of typed actor)
TODO: check if akka-camel is 'cluster-friendly'. I still need to take a look at the new akka-cluster stuff but goal is that consumer and producer actors can be clustered as well.

Anything I forgot?

Please give me feedback on the TypedActor stuff when you get to that, if there's something missing we can get that sorted.

After some initial experiments to get akka-camel-typed working, I found that method/param annotations on the interface-class are not visible through the proxy object via reflection. (The methods themselves are visible, of course). This prevents

- the current akka-camel-typed code from processing @consume annotations
- Camel from processing bean-binding annotations such as @Header, @Body etc.

With the former AspectWerkz proxies, annotations were visible. I didn't have time so far to make further investigations here (and can only do that next week).

Crap. Crap. Crap. Crap.

Annotations are the Devil™
 
Dynamic Proxy doesn't preserve the full signature of the class? I am shocked and saddened.

I want us to try to solve this without going back to loadtime/runtime weaving.

Any ideas?

Would it help at all if I could provide a way to get at either the impl or the classes used for the interface, so you can pull the annotations from there?

I can very easily expose a way for you to obtain the classes (and therefor annotations) defined on the interface.

Given: def annotationsFor(o: Class[_]) = o.getDeclaredMethods.toList.flatMap(_.getDeclaredAnnotations)

TypedActor.invocationHandlerFor(a).interfaces.flatMap(annotationsFor(_))


If you also/otherwise need the class of the implementation, it will be harder, but I don't think impossible.
 

[√iktor Ҡlang]

It was hard, but not impossible:

TypedActor.invocationHandlerFor(a).implementation <--- Class[_] of the implementation
TypedActor.invocationHandlerFor(a).interfaces <-- imm.Seq[Class[_]] of the interfaces

Does that work, or do the annotations need to be visible from the proxy.getClass itself?
 

[√iktor Ҡlang]

Output from the repl:

Welcome to Scala version 2.9.0.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_24).
Type in expressions to have them evaluated.
Type :help for more information.

scala> import akka.actor._
import akka.actor._

scala> trait IFoo { @TestAnnotation def foo = println("foo") }
defined trait IFoo

scala> class IFooI extends IFoo { @TestAnnotation(someString = "pig") def bar = println("bar") }
defined class IFooI

scala> def annotationsFor(o: Class[_]) = o.getDeclaredMethods.toList.flatMap(_.getDeclaredAnnotations)
annotationsFor: (o: Class[_])List[java.lang.annotation.Annotation]

scala> val a = TypedActor.typedActorOf(classOf[IFoo],classOf[IFooI], TypedActor.Configuration())
[INFO] [05/24/2011 11:58:16.485] [Thread-312] [EventHandler$] Starting up EventHandler
[INFO] [05/24/2011 11:58:16.486] [Thread-312] [LocalDeployer$] Deploying actors locally [
   
]
a: IFoo = Actor[58745570-85ec-11e0-afcb-60334b120057:58819be0-85ec-11e0-afcb-60334b120057]

scala> annotationsFor(TypedActor.invocationHandlerFor(a).implementation)
res0: List[java.lang.annotation.Annotation] = List(@akka.actor.TestAnnotation(someString=pigdog), @akka.actor.TestAnnotation(someString=pig))

scala> TypedActor.invocationHandlerFor(a).interfaces.flatMap(annotationsFor(_))
res1: scala.collection.immutable.Seq[java.lang.annotation.Annotation] = List(@akka.actor.TestAnnotation(someString=pigdog))


Is this sufficient?

[Martin Krasser]

Hi Viktor,

your proposal would solve the problem of processing the
akka-camel-specific @consume annotation. But in order for Camel to
process the (Camel-specific) @Header or @Body annotations, one would
need to use that specific mechanism within Camel as well, which is not
an option. Furthermore, other frameworks (that could be potentially used
by typed-actor apps) also rely on the standard Class.getAnnotations or
Class.getDeclaredAnnotations methods for annotation processing.

Sorry for only saying 'no' at the moment, without offering a solution.
Need to think more about it.

Am 24.05.11 11:59, schrieb √iktor Ҡlang:

--

[√iktor Ҡlang]

On Tue, May 24, 2011 at 12:54 PM, Martin Krasser <kras...@googlemail.com> wrote:

Hi Viktor,

your proposal would solve the problem of processing the akka-camel-specific @consume annotation. But in order for Camel to process the (Camel-specific) @Header or @Body annotations, one would need to use that specific mechanism within Camel as well, which is not an option. Furthermore, other frameworks (that could be potentially used by typed-actor apps) also rely on the standard Class.getAnnotations or Class.getDeclaredAnnotations methods for annotation processing.

Crap.
 

Sorry for only saying 'no' at the moment, without offering a solution. Need to think more about it.

I'm pretty pissed off that Proxy doesn't retain the annotations. That's plenty retarded.
 

[√iktor Ҡlang]

By the way Martin,

val a = TypedActor....

a.getClass.getInterfaces.toList.flatMap(annotationsFor)

res0: List[java.lang.annotation.Annotation] = List(@akka.actor.TestAnnotation(someString=pigdog))


So any annotations defined on the interfaces should be present on the proxies' interfaces.

It's just the a.getClass.getAnnotations etc that fail.

Don't camel/spring etc looks for the methods defined by the interfaces?

2011/5/24 √iktor Ҡlang <viktor...@gmail.com>

[Martin Krasser]

Am 24.05.11 15:05, schrieb √iktor Ҡlang:

By the way Martin,

val a = TypedActor....

a.getClass.getInterfaces.toList.flatMap(annotationsFor)

res0: List[java.lang.annotation.Annotation] = List(@akka.actor.TestAnnotation(someString=pigdog))


So any annotations defined on the interfaces should be present on the proxies' interfaces.

It's just the a.getClass.getAnnotations etc that fail.

Yeah, but this is what worked with the AspectWerkz proxy. It seems that AspectWerkz is so friendly to inherit the annotations from the interface and I simply assumed that the JDK proxy works like the AspectWerkz proxy (note to myself: RTFM).

Don't camel/spring etc looks for the methods defined by the interfaces?

Don't know yet. Will take a closer look as soon as I can. Ideally, this is really just a Camel issue, then I can fix it there.

One problem remains: the @Body and @Header annotations cannot be placed on the impl class, only the @consumer annotation (using some special processing in akka-camel) - I think that's a limitation one can easily live with (?)

[√iktor Ҡlang]

On Tue, May 24, 2011 at 9:14 PM, Martin Krasser <kras...@googlemail.com> wrote:

Am 24.05.11 15:05, schrieb √iktor Ҡlang:

By the way Martin,

val a = TypedActor....

a.getClass.getInterfaces.toList.flatMap(annotationsFor)

res0: List[java.lang.annotation.Annotation] = List(@akka.actor.TestAnnotation(someString=pigdog))


So any annotations defined on the interfaces should be present on the proxies' interfaces.

It's just the a.getClass.getAnnotations etc that fail.

Yeah, but this is what worked with the AspectWerkz proxy. It seems that AspectWerkz is so friendly to inherit the annotations from the interface and I simply assumed that the JDK proxy works like the AspectWerkz proxy (note to myself: RTFM).

I was quite surprised myself.
 

Don't camel/spring etc looks for the methods defined by the interfaces?

Don't know yet. Will take a closer look as soon as I can. Ideally, this is really just a Camel issue, then I can fix it there.

That'd be great. JDK Proxies seem to suck arse...
 

One problem remains: the @Body and @Header annotations cannot be placed on the impl class, only the @consumer annotation (using some special processing in akka-camel) - I think that's a limitation one can easily live with (?)

What happens if you put the @Body etc on the interface?
 

[Martin Krasser]

Am 24.05.11 21:20, schrieb √iktor Ҡlang:

On Tue, May 24, 2011 at 9:14 PM, Martin Krasser <kras...@googlemail.com> wrote:

Am 24.05.11 15:05, schrieb √iktor Ҡlang:

By the way Martin,

val a = TypedActor....

a.getClass.getInterfaces.toList.flatMap(annotationsFor)

res0: List[java.lang.annotation.Annotation] = List(@akka.actor.TestAnnotation(someString=pigdog))


So any annotations defined on the interfaces should be present on the proxies' interfaces.

It's just the a.getClass.getAnnotations etc that fail.

Yeah, but this is what worked with the AspectWerkz proxy. It seems that AspectWerkz is so friendly to inherit the annotations from the interface and I simply assumed that the JDK proxy works like the AspectWerkz proxy (note to myself: RTFM).

I was quite surprised myself.
 

Don't camel/spring etc looks for the methods defined by the interfaces?

Don't know yet. Will take a closer look as soon as I can. Ideally, this is really just a Camel issue, then I can fix it there.

That'd be great. JDK Proxies seem to suck arse...
 

One problem remains: the @Body and @Header annotations cannot be placed on the impl class, only the @consumer annotation (using some special processing in akka-camel) - I think that's a limitation one can easily live with (?)

What happens if you put the @Body etc on the interface?

@Body, @Header etc seems to be currently ignored by Camel when using the JDK proxy but works with the AspectWerkz proxy. But I guess that it's easy to fix for the JDK proxy.

[√iktor Ҡlang]

Would be an easy, non-breaking change to do:

if (Proxy.isProxyInstance(x)) introspect(x.getClass.getInterfaces) else introspect(x.getClass)

>>> <mailto:viktor...@gmail.com>>

>>> <tel:%5B58745570-85>ec-11e0-afcb-60334b120057:58819be0-85ec-11e0-afcb-60334b120057]

>>>
>>> scala>
>>> annotationsFor(TypedActor.invocationHandlerFor(a).implementation)
>>> res0: List[java.lang.annotation.Annotation] =
>>> List(@akka.actor.TestAnnotation(someString=pigdog),
>>> @akka.actor.TestAnnotation(someString=pig))
>>>
>>> scala>
>>> TypedActor.invocationHandlerFor(a).interfaces.flatMap(annotationsFor(_))
>>> res1:
>>> scala.collection.immutable.Seq[java.lang.annotation.Annotation]
>>> = List(@akka.actor.TestAnnotation(someString=pigdog))
>>>
>>>
>>> Is this sufficient?
>>>
>>>
>>> --
>>> Martin Krasser
>>>
>>> blog: http://krasserm.blogspot.com
>>> code: http://github.com/krasserm
>>> twitter: http://twitter.com/mrt1nz
>>>
>>>
>>>
>>>
>>> --
>>> Viktor Klang
>>>
>>> Akka Tech Lead

>>> Typesafe <http://www.typesafe.com/>- Enterprise-Grade Scala

>>> from the Experts
>>>
>>> Twitter: @viktorklang
>>>
>>>
>>>
>>>
>>> --
>>> Viktor Klang
>>>
>>> Akka Tech Lead

>>> Typesafe <http://www.typesafe.com/>- Enterprise-Grade Scala from

>>> the Experts
>>>
>>> Twitter: @viktorklang
>>>
>>
>> --
>> Martin Krasser
>>
>> blog:http://krasserm.blogspot.com
>> code:http://github.com/krasserm
>> twitter:http://twitter.com/mrt1nz
>>
>>
>>
>>
>> --
>> Viktor Klang
>>
>> Akka Tech Lead

>> Typesafe <http://www.typesafe.com/>- Enterprise-Grade Scala from the

[Martin Krasser]

Am 24.05.11 21:41, schrieb √iktor Ҡlang:

Would be an easy, non-breaking change to do:

if (Proxy.isProxyInstance(x)) introspect(x.getClass.getInterfaces) else introspect(x.getClass)

I'll propose you as a Camel committer :)

[Martin Krasser]

akka-camel-typed now works with the new typed actor implementation. I pushed my changes to branch 911-krasserm, commit https://github.com/jboner/akka/commit/efd9a895e87a445377e4547841001d1237b29083

1.) I needed to introduce some small changes to ActorRegistry.scala and TypedActor.scala:
- ActorRegistered and ActorUnregistered now also contain an optional typed actor reference. For a typed actor registration/unregistration it is Some(typedActor) otherwise None. This was needed because a typed actor lookup in the actor registry after receiving an ActorUnregistered event wasn't possible (and akka-camel-typed needs access to the typed actor after unregistration). Although this problem doesn't come up with ActorRegistered events, I extended this case class as well for reasons of symmetry.
- Registration logic of TypedActor.TypedActor was moved to ActorRegistry.registerTypedActor (better encapsulation)

2.) https://issues.apache.org/jira/browse/CAMEL-4040 is now fixed in Camel 2.8. Until it is released we'll use a patched camel-core-2.7.1.1 which has already been uploaded to the Akka Maven repo (thanks to Peter Vlugter).

3.) Open
- API doc updates
- User doc updates
- Some cosmetic changes

Can someone please review the changes?

Thanks,
Martin

Am 24.05.11 21:41, schrieb √iktor Ҡlang:

Would be an easy, non-breaking change to do:

[√iktor Ҡlang]

On Mon, Jun 6, 2011 at 2:59 AM, Martin Krasser <kras...@googlemail.com> wrote:

akka-camel-typed now works with the new typed actor implementation. I pushed my changes to branch 911-krasserm, commit https://github.com/jboner/akka/commit/efd9a895e87a445377e4547841001d1237b29083

1.) I needed to introduce some small changes to ActorRegistry.scala and TypedActor.scala:
- ActorRegistered and ActorUnregistered now also contain an optional typed actor reference. For a typed actor registration/unregistration it is Some(typedActor) otherwise None. This was needed because a typed actor lookup in the actor registry after receiving an ActorUnregistered event wasn't possible (and akka-camel-typed needs access to the typed actor after unregistration). Although this problem doesn't come up with ActorRegistered events, I extended this case class as well for reasons of symmetry.
- Registration logic of TypedActor.TypedActor was moved to ActorRegistry.registerTypedActor (better encapsulation)

Otherwise it's pretty easy to get the handle for a typed actor from an actorref: Actor.registry.typedActorFor(reference)

 

2.) https://issues.apache.org/jira/browse/CAMEL-4040 is now fixed in Camel 2.8. Until it is released we'll use a patched camel-core-2.7.1.1 which has already been uploaded to the Akka Maven repo (thanks to Peter Vlugter).

Awesome :-)
 

--

Typesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

[Martin Krasser]

Am 06.06.11 16:31, schrieb √iktor Ҡlang:

On Mon, Jun 6, 2011 at 2:59 AM, Martin Krasser <kras...@googlemail.com> wrote:

akka-camel-typed now works with the new typed actor implementation. I pushed my changes to branch 911-krasserm, commit https://github.com/jboner/akka/commit/efd9a895e87a445377e4547841001d1237b29083

1.) I needed to introduce some small changes to ActorRegistry.scala and TypedActor.scala:
- ActorRegistered and ActorUnregistered now also contain an optional typed actor reference. For a typed actor registration/unregistration it is Some(typedActor) otherwise None. This was needed because a typed actor lookup in the actor registry after receiving an ActorUnregistered event wasn't possible (and akka-camel-typed needs access to the typed actor after unregistration). Although this problem doesn't come up with ActorRegistered events, I extended this case class as well for reasons of symmetry.
- Registration logic of TypedActor.TypedActor was moved to ActorRegistry.registerTypedActor (better encapsulation)

Otherwise it's pretty easy to get the handle for a typed actor from an actorref: Actor.registry.typedActorFor(reference)

This is what I initially did. The only case where it doesn't work is after receiving an ActorUnregistered event (because then the handle is already removed from the registry).

[√iktor Ҡlang]

On Mon, Jun 6, 2011 at 7:37 AM, Martin Krasser <kras...@googlemail.com> wrote:

Am 06.06.11 16:31, schrieb √iktor Ҡlang:

On Mon, Jun 6, 2011 at 2:59 AM, Martin Krasser <kras...@googlemail.com> wrote:

akka-camel-typed now works with the new typed actor implementation. I pushed my changes to branch 911-krasserm, commit https://github.com/jboner/akka/commit/efd9a895e87a445377e4547841001d1237b29083

1.) I needed to introduce some small changes to ActorRegistry.scala and TypedActor.scala:
- ActorRegistered and ActorUnregistered now also contain an optional typed actor reference. For a typed actor registration/unregistration it is Some(typedActor) otherwise None. This was needed because a typed actor lookup in the actor registry after receiving an ActorUnregistered event wasn't possible (and akka-camel-typed needs access to the typed actor after unregistration). Although this problem doesn't come up with ActorRegistered events, I extended this case class as well for reasons of symmetry.
- Registration logic of TypedActor.TypedActor was moved to ActorRegistry.registerTypedActor (better encapsulation)

Otherwise it's pretty easy to get the handle for a typed actor from an actorref: Actor.registry.typedActorFor(reference)

This is what I initially did. The only case where it doesn't work is after receiving an ActorUnregistered event (because then the handle is already removed from the registry).

Good catch!