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 implementatio
2012/6/5 Jason Pyeron :
> 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
> -Original Message-
> From: Lukasz Lenart [mailto:[email protected]]
> 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 ha
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 (
2012/6/3 Dave Newton :
> There's VFS, maybe it'd be possible to do something with that...
Yes, I've checked Commons VFS but I'm not sure if adding the whole
huge library (with the dependencies) is a good idea. Abstraction layer
in S2 is just one interface and mostly connected with reloading
classe
There's VFS, maybe it'd be possible to do something with that...
I'm assuming the work is at least partially to support some jboss stuff,
but I'm not sure.
Dave
On Saturday, June 2, 2012, Wendy Smoak wrote:
> On Fri, Jun 1, 2012 at 5:11 PM, Dave Newton wrote:
>> That'd require manual configura
On Fri, Jun 1, 2012 at 5:11 PM, Dave Newton wrote:
> That'd require manual configuration, potentially complicating the build
> and/or deploy process, but that doesn't make it a bad idea. Grabbing it
> from a JNDI resource would be another potential solution.
>
> Not sure if it could be (reliably)
...
__
place extensive disclaimer here
> Date: Fri, 1 Jun 2012 22:20:32 +0200
> Subject: Re: Abstract layer to access file system
> From: [email protected]
> To: [email protected]
> CC: [email protected]
>
> 2012/5/31 Dave Newton :
>
That'd require manual configuration, potentially complicating the build
and/or deploy process, but that doesn't make it a bad idea. Grabbing it
from a JNDI resource would be another potential solution.
Not sure if it could be (reliably) automatic with scanning, either,
although perhaps there's alr
2012/5/31 Dave Newton :
> I think you'd have to either scan for a type or annotation; before the
> framework is up not sure what other options there could be.
Thanks Dave, but right now I think about something simpler like
specifying FileManager implementation's class as a context-param and
provid
I think you'd have to either scan for a type or annotation; before the
framework is up not sure what other options there could be.
d.
(pardon brevity and typos, on cell)
On May 31, 2012 2:12 AM, "Łukasz Lenart"
wrote:
> I need an advice ...
>
> FileManager is used in bootstrap configuration (se
I need an advice ...
FileManager is used in bootstrap configuration (see
DefaultConfiguration.createBootstrapContainer()) but this is in-code
defined configuration. Right now I've introduced FileManagerFactory to
create FileManager but it base on Container (which is created by
createBootstrapConta
Hi,
I'm going introduce an abstract layer to access file system. There are
still some issues with accessing files on different application
servers and still will be in the future when a new app server will
show up ;-)
The first step was made - FileManager is an interface right now and
can
13 matches
Mail list logo