I would like to pull the OSGi module out of the Microcontainer project into separate project (as Scott did with VFS) under 'https://svn.jboss.org/repos/jbossas/projects/osgi'. Why?
I went over the r4 spec and Spring's OSGi integration - and this is probably really the same thing we want to have. What's really important is that Spring's OSGi spec (http://www.springframework.org/osgi/specification) was influenced a lot by the same people (core OSGi EG members) that we are also involved with - so doing something totally different doesn't make sense.
Ok, the two impls would look a lot the same (if somebody has a problem with this, let me know), but I don't think we are here to reinvent the wheel. We are basically trying to put a good spec onto MC's behaviour.
And with this similar OSGi approach and our (almost) ready Spring XML schema support, I think we would offer users / developers a good option of choosing what they want to use - full app. server or simple IoC container.
Our OSGi project would be (similar to Spring's) divided into different modules. These are the one's that I currently have in mind:
- core (integration with MC)
- starter [extender] (Activator bundle)
- examples [samples]
- services (optional impl of OSGi services on top of our architecture - log, security, ...)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3996826#3996826
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3996826
Agreed that some exceptions may get serialised as return values, but as you pointed out, this is not in the list of errors.
As for other JGroups classes, those that are transported across the wire are marshalled using the TreeCacheMarshaller in 1.4.0, so this is not a problem when talking to 1.4.x.
This does break down in one scenario though; and this is when we use region-based marshalling (JBC 1.2.x/1.3.x) which forces Java serialization on the payload, including JGroups classes. (When not using region-based marshalling, JGroups Streamable interface is used, which does not make use of Java seriaization)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3996816#3996816
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3996816
1. The Valve is an interceptor.
I first wanted to implement it as an aspect, but then I had a problem of enabling/disabling the valve when we are calling a ClusteredCF and a non ClusteredCF. Another point also is... the Valve needs to be instantiated per connection, i.e. All objects created after a connection will share the same instance.
We could use ConnectionState to store the data. That was one of the questions I had on another thread but we left the discussion for later.
2. As I said on 1. ValveAspect is an interceptor. Maybe we should rename it.
I have kept is as an extension, because HAAspect is per-instance and leaves per connectionFactory, while ValveAspect is perConnection and leaves on any object created after Connection. The valve works more like a proxy.
The Valve also needs some features existent on HAAspect that's why we have the inheritance. Maybe we could merge ValveAspect into HAAspect (even I wouldn't agree, since the Valve is more like a proxy).
3. As I said on 1 and 2... The Valve is a proxy, holding any calls while failover is happening on any thread or object associated with a Connection. It's using readWriteLock to perform such feature.
Regarding the observations I will see what's going on with 2 and will change 1.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3996781#3996781
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3996781
I would like to understand the logic behind the way you implemented the Valve.
Here are some questions:
1. I noticed that ValveAspect extends HAAspect but also implements Interceptor. Why do you need to extend HAAspect? Is the Valve construct an aspect (is it intended to encapsulate multiple advices) or it is essentially an interceptor (a single advice)?
2. I don't see a ValveAspect in aop-messaging-client.xml, which means you're using it in a non-standard way. You've got to decide whether it's an aspect/interceptor, and then you initialize it consistently with the rest of the stack, or it's something else, but in that case don't call it "aspect", call it something else.
3. Please write down (no more than three-four paragraphs) the way your client-side valve is intended to work.
Some general observations:
1. Please use the commonly-accepted coding style where you guard various sections of your class file with labels (// Constants ---, // Constructors ---, etc)
2. Make sure that after you check in the $Id$ tag is correctly updated. I noticed that in your case it isn't. It has something to do with your SVN client set-up, it happened to Tim as well, and he fixed it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3996775#3996775
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3996775