On Sun, May 11, 2014 at 6:10 AM, Lukasz Lenart wrote:
> Basically we have two "core"s - and what I want to do is to merge them
> to be the real core (not divided), thus should also remove some clumsy
> code which exists in XWork-Core just to satisfy Struts-Core's needs.
> And also reduce some dupl
Instead of merging, perhaps what you really need to do is modify the XWork
API to make it more extensible. It does seem a bit crazy you need to
constantly change both. XWork should be as un-struts as possible, I think.
Cheers,
Paul
On Fri, May 9, 2014 at 1:00 AM, Lukasz Lenart wrote:
> Hi,
>
>
Basically we have two "core"s - and what I want to do is to merge them
to be the real core (not divided), thus should also remove some clumsy
code which exists in XWork-Core just to satisfy Struts-Core's needs.
And also reduce some duplication like ActionContext and
ServletActionContext.
Having on
However, on second thoughts, I would like to know the purpose of keeping
XWork separate. Was it to allow other clients besides Struts? And do any of
those exist?
My line of questioning is really about the future. If we want to clearly
separate out a Struts API and Struts Core Implementation, we sh
Not any more, I guess. I'd like to see that stuff be usable on its own
somehow, but realistically, few people use it standalone any more.
On May 10, 2014 7:09 PM, "Lukasz Lenart" wrote:
> Hi,
>
> I'm considering merging XWork code base into Struts Core module. There
> is a lot problems when I wa
Hi,
I'm considering merging XWork code base into Struts Core module. There
is a lot problems when I want to write some extension points (with
@Inject and BeanSelectionProvider) and when the same extension point
must be defined for class from XWork - I have to translate constants
to keep separation
