You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jason Pyeron <jp...@pdinc.us> on 2012/06/05 02:36:47 UTC
RE: [struts-dev] Re: Abstract layer to access file system
> -----Original Message-----
> From: Lukasz Lenart [mailto:lukasz.lenart@googlemail.com]
> Sent: Monday, June 04, 2012 7:32
> To: Struts Developers List
> Subject: [struts-dev] Re: Abstract layer to access file system
>
> Ok, got it working, but the only problem I have is that the
> all implementations provided by framework must be specified
> as a FileManagerProvider with Dispatcher class or all the
> classes (implementations of FileManager interface) have to be
> defined in
> XWork2 and added to DefaultConfiguration class (where
> bootstrap container is created).
>
> I don't know which option is best.
When I started dealing with this last year I concluded the following:
1: use the classloader as much as possible as it always works.
2: the plugin searching will fail if the bootstrap process does not know how to
"scan" the "filesystem"
3: use a "property" to pre load handler classes for a given environment.
4: let every handler be a plugin as to remove the compile & runtime time
dependencies.
I did not have a way of keeping the code in sync with trunk so it is likely lost
now. But it did work well for us.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [struts-dev] Re: Abstract layer to access file system
Posted by Łukasz Lenart <lu...@googlemail.com>.
I bit stack with this ...
What is the chance that the users will use that custom mechanism ? Is
it worth to implement something that can be a bit complicated to use ?
Anyway, I'm thinking about adding additional method to FileManager
interface like boolean isInternal() to mark which implementations are
provided by S2 and used them in second step, trying first lookup for
user specific FM (isInternal() returns false). Thus allows to override
existing implementations by users. WDYT ?
Regards
--
Łukasz
mobile +48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [struts-dev] Re: Abstract layer to access file system
Posted by Łukasz Lenart <lu...@googlemail.com>.
2012/6/5 Jason Pyeron <jp...@pdinc.us>:
> 1: use the classloader as much as possible as it always works.
The problem here is that a path to a class isn't the same as a path to a jar
> 2: the plugin searching will fail if the bootstrap process does not know how to
> "scan" the "filesystem"
Yep, solved that by init-param
> 3: use a "property" to pre load handler classes for a given environment.
What do you mean by that ? I've used ini-param option in web.xml
> 4: let every handler be a plugin as to remove the compile & runtime time
> dependencies.
I would like to add the same option, but the only problem I have now
is how to allow users to override FileManagers defined by S2. I've
introduced option to autodiscover if given FM supports [1] current fs
but this blocks option to override FMs by users. Need to find a better
solution.
[1] https://svn.apache.org/repos/asf/struts/struts2/trunk/xwork-core/src/main/java/com/opensymphony/xwork2/FileManager.java
method support()
Regards
--
Łukasz
mobile +48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org