You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by David Vittor <dv...@gmail.com> on 2015/06/23 13:09:09 UTC
Introducing the PicoContainer for Dependency Injection
Hi Devs,
Following close on the heels of the Haddock template rewrite, I've released
2.10.2-svn-18 - a small rewrite of the core WikiEngine.
I've been doing a some research into Dependency Injection, I've decided
that for JSPWiki, I think the best framework would be PicoContainer.
http://picocontainer.com/
This change will take a long time to complete, but I've started by adding
it to the pom.xml, changing the ClassUtil class to create and list all the
"components" (InternalModule), and changing these modules (SearchManager,
AdminBeanManager, WorkflowManager, DefaultFitlerManager, etc) to have empty
constructors, and a method called initialize( WikiEngine, Properties ).
Just the above change took ages to get right, but now all test cases pass,
and I've played with it in my dev environment and seems like everything
works.
I hope now that the core is in place, we can slowly start making changes to
actually use the PicoContainer functionality for dynamic component
injection.
I have made a trade off however. Currently the file "ini/classmappings.xml"
is no longer valid, and the core classes are hard coded inside "ClassUtil".
Let me know if anyone has any thoughts on this.
Kind regards,
David V
Re: Introducing the PicoContainer for Dependency Injection
Posted by Juan Pablo Santos RodrÃguez <ju...@gmail.com>.
Hi David,
this seems really interesting! I'll take a look at the branch on the
following days to see all the changes under the covers
cheers,
juan pablo
On Tue, Jun 23, 2015 at 3:32 PM, David Vittor <dv...@gmail.com> wrote:
> Yeah - that's probably a good idea. Now that it's on a branch it wont stop
> normal bug fixes and development on the trunk.
>
> The refactor should not affect most users. It's deep down in the internal
> workings of JSPWiki. It might affect those that have made major
> customisations, or those who have written custom plugins/features. But
> otherwise it will just be a normal upgrade.
>
> The main advantage will be to make it more modular, and easier to write
> TestCases and easier to internally organise/edit/add modules/components.
>
> Cheers,
> David V
>
>
> On Tue, Jun 23, 2015 at 10:06 PM, David (spindift) <demerson@spindrift.com
> >
> wrote:
>
> > If you're planning on making a large-ish refactor, it would be nice to
> > have an official release prior to introducing the changes. That would
> > consolidate the updates-to-date into a new official baseline.
> >
> > Just a thought...
> > DaveE
> >
> >
> > On 6/23/2015 7:47 AM, David Vittor wrote:
> >
> >> Hi All,
> >>
> >> I've decided to remove this from trunk, as I will be unavailable to
> >> support this for a few weeks.
> >>
> >> I've reverted the trunk and checked in the changes to a Branch:
> >>
> https://svn.apache.org/repos/asf/jspwiki/branches/JSPWIKI_2_10_PICO_BRANCH
> >>
> >> I've also attached here a pico.patch in case someone wants to test this
> >> against their version of trunk source. Apply the patch on the current
> >> version 2.10.2-svn-17.
> >>
> >> Let me know your thoughts if you do get to test this, and I'll see if I
> >> can merge this into the trunk, when I have more time.
> >>
> >> Kind regards,
> >> David V
> >>
> >>
> >> On Tue, Jun 23, 2015 at 9:09 PM, David Vittor <dvittor@gmail.com
> <mailto:
> >> dvittor@gmail.com>> wrote:
> >>
> >> Hi Devs,
> >>
> >> Following close on the heels of the Haddock template rewrite, I've
> >> released 2.10.2-svn-18 - a small rewrite of the core WikiEngine.
> >>
> >> I've been doing a some research into Dependency Injection, I've
> >> decided that for JSPWiki, I think the best framework would be
> >> PicoContainer.
> >> http://picocontainer.com/
> >>
> >> This change will take a long time to complete, but I've started by
> >> adding it to the pom.xml, changing the ClassUtil class to create
> >> and list all the "components" (InternalModule), and changing these
> >> modules (SearchManager, AdminBeanManager, WorkflowManager,
> >> DefaultFitlerManager, etc) to have empty constructors, and a
> >> method called initialize( WikiEngine, Properties ).
> >>
> >> Just the above change took ages to get right, but now all test
> >> cases pass, and I've played with it in my dev environment and
> >> seems like everything works.
> >>
> >> I hope now that the core is in place, we can slowly start making
> >> changes to actually use the PicoContainer functionality for
> >> dynamic component injection.
> >>
> >> I have made a trade off however. Currently the file
> >> "ini/classmappings.xml" is no longer valid, and the core classes
> >> are hard coded inside "ClassUtil".
> >>
> >> Let me know if anyone has any thoughts on this.
> >>
> >> Kind regards,
> >> David V
> >>
> >>
> >>
> >
>
Re: Introducing the PicoContainer for Dependency Injection
Posted by David Vittor <dv...@gmail.com>.
Yeah - that's probably a good idea. Now that it's on a branch it wont stop
normal bug fixes and development on the trunk.
The refactor should not affect most users. It's deep down in the internal
workings of JSPWiki. It might affect those that have made major
customisations, or those who have written custom plugins/features. But
otherwise it will just be a normal upgrade.
The main advantage will be to make it more modular, and easier to write
TestCases and easier to internally organise/edit/add modules/components.
Cheers,
David V
On Tue, Jun 23, 2015 at 10:06 PM, David (spindift) <de...@spindrift.com>
wrote:
> If you're planning on making a large-ish refactor, it would be nice to
> have an official release prior to introducing the changes. That would
> consolidate the updates-to-date into a new official baseline.
>
> Just a thought...
> DaveE
>
>
> On 6/23/2015 7:47 AM, David Vittor wrote:
>
>> Hi All,
>>
>> I've decided to remove this from trunk, as I will be unavailable to
>> support this for a few weeks.
>>
>> I've reverted the trunk and checked in the changes to a Branch:
>> https://svn.apache.org/repos/asf/jspwiki/branches/JSPWIKI_2_10_PICO_BRANCH
>>
>> I've also attached here a pico.patch in case someone wants to test this
>> against their version of trunk source. Apply the patch on the current
>> version 2.10.2-svn-17.
>>
>> Let me know your thoughts if you do get to test this, and I'll see if I
>> can merge this into the trunk, when I have more time.
>>
>> Kind regards,
>> David V
>>
>>
>> On Tue, Jun 23, 2015 at 9:09 PM, David Vittor <dvittor@gmail.com <mailto:
>> dvittor@gmail.com>> wrote:
>>
>> Hi Devs,
>>
>> Following close on the heels of the Haddock template rewrite, I've
>> released 2.10.2-svn-18 - a small rewrite of the core WikiEngine.
>>
>> I've been doing a some research into Dependency Injection, I've
>> decided that for JSPWiki, I think the best framework would be
>> PicoContainer.
>> http://picocontainer.com/
>>
>> This change will take a long time to complete, but I've started by
>> adding it to the pom.xml, changing the ClassUtil class to create
>> and list all the "components" (InternalModule), and changing these
>> modules (SearchManager, AdminBeanManager, WorkflowManager,
>> DefaultFitlerManager, etc) to have empty constructors, and a
>> method called initialize( WikiEngine, Properties ).
>>
>> Just the above change took ages to get right, but now all test
>> cases pass, and I've played with it in my dev environment and
>> seems like everything works.
>>
>> I hope now that the core is in place, we can slowly start making
>> changes to actually use the PicoContainer functionality for
>> dynamic component injection.
>>
>> I have made a trade off however. Currently the file
>> "ini/classmappings.xml" is no longer valid, and the core classes
>> are hard coded inside "ClassUtil".
>>
>> Let me know if anyone has any thoughts on this.
>>
>> Kind regards,
>> David V
>>
>>
>>
>
Re: Introducing the PicoContainer for Dependency Injection
Posted by "David (spindift)" <de...@spindrift.com>.
If you're planning on making a large-ish refactor, it would be nice to
have an official release prior to introducing the changes. That would
consolidate the updates-to-date into a new official baseline.
Just a thought...
DaveE
On 6/23/2015 7:47 AM, David Vittor wrote:
> Hi All,
>
> I've decided to remove this from trunk, as I will be unavailable to
> support this for a few weeks.
>
> I've reverted the trunk and checked in the changes to a Branch:
> https://svn.apache.org/repos/asf/jspwiki/branches/JSPWIKI_2_10_PICO_BRANCH
>
> I've also attached here a pico.patch in case someone wants to test
> this against their version of trunk source. Apply the patch on the
> current version 2.10.2-svn-17.
>
> Let me know your thoughts if you do get to test this, and I'll see if
> I can merge this into the trunk, when I have more time.
>
> Kind regards,
> David V
>
>
> On Tue, Jun 23, 2015 at 9:09 PM, David Vittor <dvittor@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi Devs,
>
> Following close on the heels of the Haddock template rewrite, I've
> released 2.10.2-svn-18 - a small rewrite of the core WikiEngine.
>
> I've been doing a some research into Dependency Injection, I've
> decided that for JSPWiki, I think the best framework would be
> PicoContainer.
> http://picocontainer.com/
>
> This change will take a long time to complete, but I've started by
> adding it to the pom.xml, changing the ClassUtil class to create
> and list all the "components" (InternalModule), and changing these
> modules (SearchManager, AdminBeanManager, WorkflowManager,
> DefaultFitlerManager, etc) to have empty constructors, and a
> method called initialize( WikiEngine, Properties ).
>
> Just the above change took ages to get right, but now all test
> cases pass, and I've played with it in my dev environment and
> seems like everything works.
>
> I hope now that the core is in place, we can slowly start making
> changes to actually use the PicoContainer functionality for
> dynamic component injection.
>
> I have made a trade off however. Currently the file
> "ini/classmappings.xml" is no longer valid, and the core classes
> are hard coded inside "ClassUtil".
>
> Let me know if anyone has any thoughts on this.
>
> Kind regards,
> David V
>
>
Re: Introducing the PicoContainer for Dependency Injection
Posted by David Vittor <dv...@gmail.com>.
Hi All,
I've decided to remove this from trunk, as I will be unavailable to support
this for a few weeks.
I've reverted the trunk and checked in the changes to a Branch:
https://svn.apache.org/repos/asf/jspwiki/branches/JSPWIKI_2_10_PICO_BRANCH
I've also attached here a pico.patch in case someone wants to test this
against their version of trunk source. Apply the patch on the current
version 2.10.2-svn-17.
Let me know your thoughts if you do get to test this, and I'll see if I can
merge this into the trunk, when I have more time.
Kind regards,
David V
On Tue, Jun 23, 2015 at 9:09 PM, David Vittor <dv...@gmail.com> wrote:
> Hi Devs,
>
> Following close on the heels of the Haddock template rewrite, I've
> released 2.10.2-svn-18 - a small rewrite of the core WikiEngine.
>
> I've been doing a some research into Dependency Injection, I've decided
> that for JSPWiki, I think the best framework would be PicoContainer.
> http://picocontainer.com/
>
> This change will take a long time to complete, but I've started by adding
> it to the pom.xml, changing the ClassUtil class to create and list all the
> "components" (InternalModule), and changing these modules (SearchManager,
> AdminBeanManager, WorkflowManager, DefaultFitlerManager, etc) to have empty
> constructors, and a method called initialize( WikiEngine, Properties ).
>
> Just the above change took ages to get right, but now all test cases pass,
> and I've played with it in my dev environment and seems like everything
> works.
>
> I hope now that the core is in place, we can slowly start making changes
> to actually use the PicoContainer functionality for dynamic component
> injection.
>
> I have made a trade off however. Currently the file
> "ini/classmappings.xml" is no longer valid, and the core classes are hard
> coded inside "ClassUtil".
>
> Let me know if anyone has any thoughts on this.
>
> Kind regards,
> David V
>
>