Opinions on "conditional" Spring files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Opinions on "conditional" Spring files

Cantor, Scott E.
I've managed to wire in the ability to take some of the "occasionally used by advanced deployers" Spring files and potentially turn them into "conditional" imports in the IdP so that the files don't have to be pre-installed and clutter the configuration tree and could be created only if needed by a deployer.

I'm not sure if this is better or not, I think there are arguments both ways in terms of clarity over how to do certain things when you don't know where a file is meant to be placed. It's possible this might be limited to the more unusual cases that almost nobody would ever use, but not as much of a concerted effort to remove as many of the rarely used files.

As an example:

There's a way to override very low level MVC beans by creating conf/mvc-beans.xml, which is currently preinstalled by default as an empty Spring file. The alternative is to not create that file by default but the IdP would load it if it's present. In the log, you get some INFO-level indications when a conditional file is "skipped" because it's not created.

I'm happy that it's possible, but I'm not wedded to using it necessarily, or perhaps not all that widely, but figured it might be worth asking.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Opinions on "conditional" Spring files

Rod Widdowson
 
> I've managed to wire in the ability to take some of the "occasionally used by advanced deployers" Spring files and potentially
turn them
> into "conditional" imports in the IdP so that the files don't have to be pre-installed and clutter the configuration tree and
could be created
> only if needed by a deployer.

Bearing in mind always that I am not a deployer, or at best an occasional one, I think I actually prefer having (functionally) empty
placeholder files in the deployer's config space.  It sort of leads one towards doing things the right way without having to find
out in the documentation how to do it.  At the same time, with less developer presence in the users' list people might waste
someones time until they hit on the/a right way to do something.

Against that of course is the fact that people do get overwhelmed by the sheer number of files that we give them to play with.  It
seems to me that because of the inherent complexity, people tend to put all their beans in globals.xml rather than exploiting the
locality (and hence reloadability) available to them.

Finally if we went this way we'd need to think through the installer (strictly speaking the ant script) implications carefully.  It
won't be rocket science but it will need some test and thought.  And I hate having to crack that file open....

R

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Opinions on "conditional" Spring files

Cantor, Scott E.
On 12/31/17, 8:57 AM, "dev on behalf of Rod Widdowson" <[hidden email] on behalf of [hidden email]> wrote:

> Bearing in mind always that I am not a deployer, or at best an occasional one, I think I actually prefer having
> (functionally) empty placeholder files in the deployer's config space.  It sort of leads one towards doing things the right
> way without having to find out in the documentation how to do it.  At the same time, with less developer presence in
> the users' list people might waste someones time until they hit on the/a right way to do something.

I tend to agree, that's why I was hesitant to just start replacing empty files all over the place. But I do think there's a reasonable boundary between "might be used" and "almost never relevant to 99% of deployers", so judiciously used I think we can get rid of a few of them at least.

Unfortunately one of the places I'd really like to add this is inside the flow bean files, but that Spring context doesn't have the ability to handle this.

> Finally if we went this way we'd need to think through the installer (strictly speaking the ant script) implications
> carefully.  It won't be rocket science but it will need some test and thought.  And I hate having to crack that file open....

The intention would be that any file that's already there never gets touched, which I think is already true.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Opinions on "conditional" Spring files

O'Dowd, Josh
> Unfortunately one of the places I'd really like to add this is inside the flow bean files, but that Spring context doesn't have the ability to handle this.

I am looking forward to the day when Web-flow offers Java-based configuration.  Having done some Spring/Spring-security projects with fully annotated Java config (no xml), the project clutter is a non-issue, and allows for better encapsulation practices.

By way of feedback, UM is using files like /conf/authn/authn-events-flow.xml and /conf/intercept/intercept-events-flow.xml, if those are the types of files you are referring to.

Josh
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Opinions on "conditional" Spring files

Cantor, Scott E.
On 1/2/18, 5:44 PM, "dev on behalf of O'Dowd, Josh" <[hidden email] on behalf of Josh.O'[hidden email]> wrote:

> I am looking forward to the day when Web-flow offers Java-based configuration.

Annotations are fine for prototypes and for local add-ons, but it's impossible for us to use in the core.
 
It will never work with SWF anyway, it's a virtually dead project that isn't getting any functional updates.

> Having done some Spring/Spring-> security projects with fully annotated Java config (no xml), the project clutter is a
> non-issue, and allows for better encapsulation practices.

Yes, but we can't hardwire our system.

> By way of feedback, UM is using files like /conf/authn/authn-events-flow.xml and /conf/intercept/intercept-events-
> flow.xml, if those are the types of files you are referring to.

No, I'm talking about beans files only, and it doesn't work with beans imported into flows at all.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Opinions on "conditional" Spring files

Tom Zeller-3
In reply to this post by Cantor, Scott E.
> I think we can get rid of a few of them at least.

Sounds good to me.

Just curious which files in addition to what you've mentioned already.

> Unfortunately one of the places I'd really like to add this is inside the flow bean files, but that Spring context doesn't have the ability to handle this.

I wonder if it's possible to either inject custom beans into the SWF
flow application context or override the method that instantiates it.

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Opinions on "conditional" Spring files

Cantor, Scott E.
On 1/3/18, 5:28 PM, "dev on behalf of Tom Zeller" <[hidden email] on behalf of [hidden email]> wrote:

> Just curious which files in addition to what you've mentioned already.

Haven't reviewed the full set, but candidates would be anything that got added as an import post-3.0 because it probably was added to deal with edge cases.
 
> I wonder if it's possible to either inject custom beans into the SWF flow application context or override the method that
> instantiates it.

The context gets created by a class called FlowModelFlowBuilder, and it's buried about 3 layers deep from anything that's explicitly overrideable or even that I've already cloned.

As I think I said, we're pretty close to just having a conversation about forking. When they basically stop fixing bugs or putting out even minor improvements, I can't imagine it's that hard to just track the occasional security fix. It's a dead library, yet another that refuses to admit it for whatever weird reason causes these libraries to zombify in silence.
 
-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Opinions on "conditional" Spring files

Rod Widdowson
> Haven't reviewed the full set, but candidates would be anything that got added as an import post-3.0 because it probably was added
to
> deal with edge cases.

That makes a lot of sense.  Edge conditions would argue envelope pushing deployments and I'd guess that these sort of deployers will
know the documentation (and Spring) well enough to be able to exploit this.
 
> As I think I said, we're pretty close to just having a conversation about forking.

Sadly that makes sense.  In particular (although this may be unrelated) isn't the Velocity nonsense all in this space too?

> . It's a dead library, yet another that refuses to
> admit it for whatever weird reason causes these libraries to zombify in silence.

Ah yes.  There's at least one SP dependency like that too isn't there? Although the SP begins to cause my brain to explode because
it has the confusion of Vendors who tend to mess things up by shipping their own builds.  Kinda, sometimes...

R

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Opinions on "conditional" Spring files

Cantor, Scott E.
On 1/4/18, 10:08 AM, "dev on behalf of Rod Widdowson" <[hidden email] on behalf of [hidden email]> wrote:

> Sadly that makes sense.  In particular (although this may be unrelated) isn't the Velocity nonsense all in this space too?

It's orphaned but it's a lot less code to copy over, the basic ViewResolver isn't much. That's a Spring problem rather than a SWF problem.

> Ah yes.  There's at least one SP dependency like that too isn't there?

Effectively Xerces and Santuario were both dead in the sense that I'm the only real maintainer, so whether I forked or not isn't all that material. Though somebody has shown up to work a bit on Xerces again, not enough to really make it a viable project but at least splits a little of the load. But Red Hat stopped applying security fixes to the version they shipped, so I won't ever be supporting their version again and I hope they stop shipping it.
 
-- Scott


--
To unsubscribe from this list send an email to [hidden email]