Thanks Corey, i will have a look at it this week.
Am 17.04.2011 00:28, schrieb Corey Kaylor:
I have pushed the Autofac branch.
On Sat, Apr 16, 2011 at 11:52 AM, Corey Kaylor<[email protected]> wrote:
The biggest change is configuration. It has its own traditional
configuration section now. Anyone using a load balancer would need to point
to the container specific LoadBalancerBootStrapper. If wiring things up
yourself, there is a *slight* change from using a facility, but very
minimal. It took me all of 30 seconds to update our projects with the
changes, granted I am more familiar with them.
I'll post a separate thread as requested detailing the changes required to
update.
On Sat, Apr 16, 2011 at 11:43 AM, Mike Nichols<[email protected]>wrote:
What braking changes are there? If it just means another assembly and
behavior is the same I say go for it. The castle dep has been a numbs one
obstacle to this projects adoption. There is one thing I may have a problem
with but will check that branch when I get home.
On Apr 15, 2011 3:24 AM, "Steve Wagner"<[email protected]> wrote:
Ok that is much better. I fallen about that branch right after ive send
the message.
What you can do is simply. Make an announcement about the change and
what breaking changes are there. Then give the people an ultimatum to
answer (in example 7 days) and if no one have a reason against it, do
the merge.
Since i mainly interested in using ESB with Autofac, where can i help
you with the Autofac parts?
-Steve
On 14.04.2011 23:50, Corey Kaylor wrote:
Sounds very similar to the work I did as well, including configuration
changes, etc. Did you by chance look at the branch I have on github? My
only
reservation to merging into master is that certain people who don't
seem to
have an opinion will likely have one after the fact and I don't really
have
a lot of free time on my hands at the moment. I would love to close
this out
though, we've been using StructureMap with RSB for some time now and
it's
working out well. I also have a 80% implemented Autofac container as
well.
https://github.com/hibernating-rhinos/rhino-esb/tree/servicelocator
Thoughts?
On Thu, Apr 14, 2011 at 1:03 PM, Steve Wagner<[email protected]> wrote:
Ok lets bring this a bit forward!
https://github.com/lanwin/rhino-esb
Ive created a fork and extracted all Windsor specific stuff to an
Rhino.ServiceBus.Windsor assembly. Then I've replaced all usages of
the
Kernel in the core parts with an IContainerAdapter interface and added
an
impl of it to the Rhino.ServiceBus.Windsor. This assembly contains
mostly
configuration,facilities and hosts.
It works, all tests pass and the Starbucks example runs. The only
problem
is that the Starbucks.Tests dont run because it dose not Shadowcopy
both
assemblies. Maybe someone else has an idea why?!?
If we now move the common functionality of the
configuration,facilities and
hosts to more abstract base classes, we have a pretty good extension
point
for using another container. Also Windsor could stay the main
container of
RSB.
For existing users there is nearly no migration overhead. They only
need to
add the new assembly and they are done, no breaking changes.
If the second assembly is really a problem, we could provide an second
ilmerged distribution package.
Thoughts?
-Steve
On 01.02.2011 23:02, Corey Kaylor wrote:
It is both 3.5 and 4.0 currently, 4.0 is built from the powershell
script.
Although all that is negotiable depending on the route chosen.
--
You received this message because you are subscribed to the Google
Groups
"Rhino Tools Dev" group.
To post to this group, send email to [email protected]
.
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en.
--
You received this message because you are subscribed to the Google
Groups "Rhino Tools Dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Rhino Tools Dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups "Rhino
Tools Dev" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en.
