Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

add CFMLResource interface

Description

The current virtual Filesystem interface “Resource“ was implemented with the goal to reflect java.io.File as close as possible, to make migration as easy as possible back then.

Problem is the current interface does not meet the requirements of CFML very well

So for example when you do a directory rename, all the following is done BEFORE “moveTo“ is called

 

if (!directory.exists()) throw new ApplicationException("the directory [" + directory.toString() + "] doesn't exist"); if (!directory.isDirectory()) throw new ApplicationException("the file [" + directory.toString() + "] exists, but it isn't a directory"); if (!directory.canRead()) throw new ApplicationException("no access to read directory [" + directory.toString() + "]"); if (strNewdirectory == null) throw new ApplicationException("the attribute [newDirectory] is not defined"); // real to source Resource newdirectory = toDestination(pc, strNewdirectory, directory); securityManager.checkFileLocation(pc.getConfig(), newdirectory, serverPassword); if (newdirectory.exists()) throw new ApplicationException("new directory [" + newdirectory.toString() + "] already exists"); if (createPath) { newdirectory.getParentResource().mkdirs(); }

This are a lot of operations that are necessary to follow the CFML rules, but they create a load of load on the virtual file system, so there should be a interface “CFMLResource“ that are specific to this CFML rename, then the virtual Filesystem itself can take care of this. For example line 13 will not really be necessary in most cases with the S3 Resource.

A virtual filesystem can but most not necessary must implement that interface.

First step of this ticket is to define the interface itself, then we create a proxy class “CFMLResourceProxy“ that wraps a resource not implementing this interface, similar to UDFProxy.

The interface should not overwrite existing methods, this could be confusing, for example the Resource interface has the methods “copyFrom“ and “copyTo“, the “CFMLResource“ interface should have the same but including the CFML logic. So they maybe should be called

  • cfmlCopyFrom

  • cfmlCopyTo

  • cfmlMoveFrom

  • cfmlMoveTo

Activity

Show:
Zac Spitzer
updated the Labels13 October 2022 at 16:56
interface java resources
interface java performance resources
Zac Spitzer
updated the Labels13 October 2022 at 16:56
interface java
interface java resources
Zac Spitzer
updated the Description24 May 2022 at 08:53
The current virtual Filesystem interface “Resource“ was implemented with the goal to reflect java.io.File as close as possible, to make migration as easy as possible back then. Problem is the this interface not matches the need of CFML very good. So for example when you do a directory rename, all the following is done BEFORE “moveTo“ is called {noformat}if (!directory.exists()) throw new ApplicationException("the directory [" + directory.toString() + "] doesn't exist"); if (!directory.isDirectory()) throw new ApplicationException("the file [" + directory.toString() + "] exists, but it isn't a directory"); if (!directory.canRead()) throw new ApplicationException("no access to read directory [" + directory.toString() + "]"); if (strNewdirectory == null) throw new ApplicationException("the attribute [newDirectory] is not defined"); // real to source Resource newdirectory = toDestination(pc, strNewdirectory, directory); securityManager.checkFileLocation(pc.getConfig(), newdirectory, serverPassword); if (newdirectory.exists()) throw new ApplicationException("new directory [" + newdirectory.toString() + "] already exists"); if (createPath) { newdirectory.getParentResource().mkdirs(); }{noformat} This are a lot of operations that are necessary to follow the CFML rules, but they create a load of load on the virtual file system, so there should be a interface “CFMLResource“ that are specific to this CFML rename, then the virtual Filesystem itself can take care of this. For example line 13 will not really be necessary in most cases with the S3 Resource. A virtual filesystem can but most not necessary must implement that interface. First step of this ticket is to define the interface itself, then we create a proxy class “CFMLResourceProxy“ that wraps a resource not implementing this interface, similar to UDFProxy. The interface should not overwrite existing methods, this could be confusing, for example the Resource interface has the methods “copyFrom“ and “copyTo“, the “CFMLResource“ interface should have the same but including the CFML logic. So they maybe should be called * cfmlCopyFrom * cfmlCopyTo * cfmlMoveFrom * cfmlMoveTo
The current virtual Filesystem interface “Resource“ was implemented with the goal to reflect java.io.File as close as possible, to make migration as easy as possible back then. Problem is the current interface does not meet the requirements of CFML very well So for example when you do a directory rename, all the following is done BEFORE “moveTo“ is called {noformat}if (!directory.exists()) throw new ApplicationException("the directory [" + directory.toString() + "] doesn't exist"); if (!directory.isDirectory()) throw new ApplicationException("the file [" + directory.toString() + "] exists, but it isn't a directory"); if (!directory.canRead()) throw new ApplicationException("no access to read directory [" + directory.toString() + "]"); if (strNewdirectory == null) throw new ApplicationException("the attribute [newDirectory] is not defined"); // real to source Resource newdirectory = toDestination(pc, strNewdirectory, directory); securityManager.checkFileLocation(pc.getConfig(), newdirectory, serverPassword); if (newdirectory.exists()) throw new ApplicationException("new directory [" + newdirectory.toString() + "] already exists"); if (createPath) { newdirectory.getParentResource().mkdirs(); }{noformat} This are a lot of operations that are necessary to follow the CFML rules, but they create a load of load on the virtual file system, so there should be a interface “CFMLResource“ that are specific to this CFML rename, then the virtual Filesystem itself can take care of this. For example line 13 will not really be necessary in most cases with the S3 Resource. A virtual filesystem can but most not necessary must implement that interface. First step of this ticket is to define the interface itself, then we create a proxy class “CFMLResourceProxy“ that wraps a resource not implementing this interface, similar to UDFProxy. The interface should not overwrite existing methods, this could be confusing, for example the Resource interface has the methods “copyFrom“ and “copyTo“, the “CFMLResource“ interface should have the same but including the CFML logic. So they maybe should be called * cfmlCopyFrom * cfmlCopyTo * cfmlMoveFrom * cfmlMoveTo
Zac Spitzer
updated the Labels24 May 2022 at 08:52
None
interface java
Michael Offner
updated the Description24 May 2022 at 07:59
The current virtual Filesystem interface “Resource“ was implemented with the goal to reflect java.io.File as close as possible, to make migration as easy as possible back then. Problem is the this interface not matches the need of CFML very good. So for example when you do a directory rename, all the following is done BEFORE “moveTo“ is called {noformat}if (!directory.exists()) throw new ApplicationException("the directory [" + directory.toString() + "] doesn't exist"); if (!directory.isDirectory()) throw new ApplicationException("the file [" + directory.toString() + "] exists, but it isn't a directory"); if (!directory.canRead()) throw new ApplicationException("no access to read directory [" + directory.toString() + "]"); if (strNewdirectory == null) throw new ApplicationException("the attribute [newDirectory] is not defined"); // real to source Resource newdirectory = toDestination(pc, strNewdirectory, directory); securityManager.checkFileLocation(pc.getConfig(), newdirectory, serverPassword); if (newdirectory.exists()) throw new ApplicationException("new directory [" + newdirectory.toString() + "] already exists"); if (createPath) { newdirectory.getParentResource().mkdirs(); }{noformat} This are a lot of operations that are necessary to follow the CFML rules, but they create a load of load on the virtual file system, so there should be a interface “CFMLResource“ that are specific to this CFML rename, then the virtual Filesystem itself can take care of this. For example line 13 will not really be necessary in most cases with the S3 Resource. A virtual filesystem can but most not necessary must implement that interface. First step of this ticket is to define the interface itself, then we create a proxy class “CFMLResourceProxy“ that wraps a resource not implementing this interface, similar to UDFProxy.
The current virtual Filesystem interface “Resource“ was implemented with the goal to reflect java.io.File as close as possible, to make migration as easy as possible back then. Problem is the this interface not matches the need of CFML very good. So for example when you do a directory rename, all the following is done BEFORE “moveTo“ is called {noformat}if (!directory.exists()) throw new ApplicationException("the directory [" + directory.toString() + "] doesn't exist"); if (!directory.isDirectory()) throw new ApplicationException("the file [" + directory.toString() + "] exists, but it isn't a directory"); if (!directory.canRead()) throw new ApplicationException("no access to read directory [" + directory.toString() + "]"); if (strNewdirectory == null) throw new ApplicationException("the attribute [newDirectory] is not defined"); // real to source Resource newdirectory = toDestination(pc, strNewdirectory, directory); securityManager.checkFileLocation(pc.getConfig(), newdirectory, serverPassword); if (newdirectory.exists()) throw new ApplicationException("new directory [" + newdirectory.toString() + "] already exists"); if (createPath) { newdirectory.getParentResource().mkdirs(); }{noformat} This are a lot of operations that are necessary to follow the CFML rules, but they create a load of load on the virtual file system, so there should be a interface “CFMLResource“ that are specific to this CFML rename, then the virtual Filesystem itself can take care of this. For example line 13 will not really be necessary in most cases with the S3 Resource. A virtual filesystem can but most not necessary must implement that interface. First step of this ticket is to define the interface itself, then we create a proxy class “CFMLResourceProxy“ that wraps a resource not implementing this interface, similar to UDFProxy. The interface should not overwrite existing methods, this could be confusing, for example the Resource interface has the methods “copyFrom“ and “copyTo“, the “CFMLResource“ interface should have the same but including the CFML logic. So they maybe should be called * cfmlCopyFrom * cfmlCopyTo * cfmlMoveFrom * cfmlMoveTo
Michael Offner
created the Issue24 May 2022 at 07:54

Details

Assignee

Reporter

Labels

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Priority

Created 24 May 2022 at 07:54
Updated 13 October 2022 at 16:56

Flag notifications