Re : svn commit: r685401 - /mina/trunk/core/pom.xml

[Edouard De Oliveira]

Hi guys,
+1 to dependency discussion. I didn't know we could just add some apache class 
in in order to avoid adding dependencies to the core.
In fact, the code used the class and i thought it was preferable to import the 
dependency to avoid code dup so i modified it just before committing.
Talking abouts this, i'm relatively new to maven but parent pom already enlists 
commons-codec as a dependency 
why do the core child pom can't beneficiate from this dependency ?
I'll correct the headers tonight : as the svn tag says, its only the initial 
commit and it was done on 2:00 AM 
There are other points to discuss about the code but i wanted to commit it to 
trunk to give all the opportunity to start test driving it.
Cordialement, Regards,
-Edouard De Oliveira-
http://tedorg.free.fr/en/main.php



- Message d'origine 
De : Emmanuel Lecharny <[EMAIL PROTECTED]>
À : dev@mina.apache.org
Envoyé le : Mercredi, 13 Août 2008, 8h36mn 09s
Objet : Re: svn commit: r685401 - /mina/trunk/core/pom.xml

Julien Vermillard wrote:
> Hi,
>
> I think we need to discuss this extra core dependency, perhaps we need
> to move proxy support as a module ?
>  
Is this used to do base64 decoding/encoding ?

If so, it might be enough to import the class we need, as Julien suggested.

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org


  
_ 
Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr

Re: svn commit: r685389 [4/4] - in /mina/trunk/core/src/main/java/org/apache/mina/proxy: ./ event/ filter/ handlers/ handlers/http/ handlers/http/basic/ handlers/http/digest/ handlers/http/ntlm/ handl

[Emmanuel Lecharny]

Julien Vermillard wrote:

Sorry but -1 here, the headers and authors tags are wrong and javadoc
is not clear and not on all the parameters (copyDirective)
and at the end of file you even have  javadoc less public methods.
  

Choppé par les keufs ! :)

Ok, the @author tags should contains a ref to the mina dev list. It has 
been decided years ago. This is not a common Apache rule, but many 
projects do so. (And it's good not to receive mails from people using 
your code years after it has been committed :)


Julien, is there something else in the header which need to be fixed ?

(About the missing javadoc for public method, it might just have gone 
through the radar).


Thanks Julien for the review ! (And thanks Edouard for the big commit !)

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: svn commit: r685389 [4/4] - in /mina/trunk/core/src/main/java/org/apache/mina/proxy: ./ event/ filter/ handlers/ handlers/http/ handlers/http/basic/ handlers/http/digest/ handlers/http/ntlm/ handl

[Julien Vermillard]

Sorry but -1 here, the headers and authors tags are wrong and javadoc
is not clear and not on all the parameters (copyDirective)
and at the end of file you even have  javadoc less public methods.

2008/8/13  <[EMAIL PROTECTED]>:
> Added: 
> mina/trunk/core/src/main/java/org/apache/mina/proxy/utils/StringUtilities.java
> URL: 
> http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/proxy/utils/StringUtilities.java?rev=685389&view=auto
> ==
> --- 
> mina/trunk/core/src/main/java/org/apache/mina/proxy/utils/StringUtilities.java
>  (added)
> +++ 
> mina/trunk/core/src/main/java/org/apache/mina/proxy/utils/StringUtilities.java
>  Tue Aug 12 17:05:41 2008
> @@ -0,0 +1,313 @@
> +/*
> + *  Licensed to the Apache Software Foundation (ASF) under one
> + *  or more contributor license agreements.  See the NOTICE file
> + *  distributed with this work for additional information
> + *  regarding copyright ownership.  The ASF licenses this file
> + *  to you under the Apache License, Version 2.0 (the
> + *  "License"); you may not use this file except in compliance
> + *  with the License.  You may obtain a copy of the License at
> + *
> + *http://www.apache.org/licenses/LICENSE-2.0
> + *
> + *  Unless required by applicable law or agreed to in writing,
> + *  software distributed under the License is distributed on an
> + *  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + *  KIND, either express or implied.  See the License for the
> + *  specific language governing permissions and limitations
> + *  under the License.
> + *
> + */
> +package org.apache.mina.proxy.utils;
> +
> +import java.io.ByteArrayOutputStream;
> +import java.io.UnsupportedEncodingException;
> +import java.util.ArrayList;
> +import java.util.HashMap;
> +import java.util.List;
> +import java.util.Map;
> +
> +import javax.security.sasl.AuthenticationException;
> +import javax.security.sasl.SaslException;
> +
> +/**
> + * StringUtilities.java - Various methods to handle strings.
> + * Note: Some code has been borrowed from  href="http://tedorg.free.fr/en/projects.php";>Mailster 
> + *
> + * @author mailto:[EMAIL PROTECTED]">Edouard De Oliveira
> + * @version $Id: $
> + */
> +public class StringUtilities {
> +
> +/**
> + * Returns the value of a directive from the map. If mandatory is true 
> and the value is null,
> + * then it throws a [EMAIL PROTECTED] AuthenticationException}.
> + */
> +public static String getDirectiveValue(
> +HashMap directivesMap, String directive,
> +boolean mandatory) throws AuthenticationException {
> +String value = directivesMap.get(directive);
> +if (value == null) {
> +if (mandatory) {
> +throw new AuthenticationException("\"" + directive
> ++ "\" mandatory directive is missing");
> +} else {
> +return "";
> +}
> +}
> +
> +return value;
> +}
> +
> +/**
> + * Copy the directive to the [EMAIL PROTECTED] StringBuilder} if not 
> null.
> + */
> +public static String copyDirective(HashMap directives,
> +StringBuilder sb, String directive) {
> +String directiveValue = directives.get(directive);
> +if (directiveValue != null) {
> +sb.append(directive).append(" = 
> \"").append(directiveValue).append(
> +"\", ");
> +}
> +
> +return directiveValue;
> +}
> +
> +/**
> + * Copy the directive to the from src to dst if not null.
> + */
> +public static String copyDirective(HashMap src,
> +HashMap dst, String directive) {
> +String directiveValue = src.get(directive);
> +if (directiveValue != null) {
> +dst.put(directive, directiveValue);
> +}
> +
> +return directiveValue;
> +}
> +
> +/**
> + * Parses digest-challenge string, extracting each token
> + * and value(s)
> + *
> + * @param buf A non-null digest-challenge string.
> + * @throws UnsupportedEncodingException
> + * @throws SaslException if the String cannot be parsed according to RFC 
> 2831
> + */
> +public static HashMap parseDirectives(byte[] buf)
> +throws SaslException {
> +HashMap map = new HashMap();
> +boolean gettingKey = true;
> +boolean gettingQuotedValue = false;
> +boolean expectSeparator = false;
> +byte bch;
> +
> +ByteArrayOutputStream key = new ByteArrayOutputStream(10);
> +ByteArrayOutputStream value = new ByteArrayOutputStream(10);
> +
> +int i = skipLws(buf, 0);
> +while (i < buf.length) {
> +bch = buf[i];
> +
> +if (gettingKey) {
> +if (bch == ',') {
> +if (key.size() != 0) {
> +throw new SaslException("Directi

Re: svn commit: r685401 - /mina/trunk/core/pom.xml

[Emmanuel Lecharny]

Julien Vermillard wrote:

Hi,

I think we need to discuss this extra core dependency, perhaps we need
to move proxy support as a module ?
  

Is this used to do base64 decoding/encoding ?

If so, it might be enough to import the class we need, as Julien suggested.

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: svn commit: r685401 - /mina/trunk/core/pom.xml

[Niklas Gustavsson]

On Wed, Aug 13, 2008 at 8:17 AM, Julien Vermillard
<[EMAIL PROTECTED]> wrote:
> I think we need to discuss this extra core dependency, perhaps we need
> to move proxy support as a module ?

+1

/niklas

Re: svn commit: r685401 - /mina/trunk/core/pom.xml

[Julien Vermillard]

Hi,

I think we need to discuss this extra core dependency, perhaps we need
to move proxy support as a module ?

Julien

2008/8/13  <[EMAIL PROTECTED]>:
> Author: edeoliveira
> Date: Tue Aug 12 17:44:41 2008
> New Revision: 685401
>
> URL: http://svn.apache.org/viewvc?rev=685401&view=rev
> Log:
> Added dependency on commons-codec base64 classes
>
> Modified:
>mina/trunk/core/pom.xml
>
> Modified: mina/trunk/core/pom.xml
> URL: 
> http://svn.apache.org/viewvc/mina/trunk/core/pom.xml?rev=685401&r1=685400&r2=685401&view=diff
> ==
> --- mina/trunk/core/pom.xml (original)
> +++ mina/trunk/core/pom.xml Tue Aug 12 17:44:41 2008
> @@ -43,6 +43,13 @@
>   org.easymock
>   easymockclassextension
> 
> +
> +
> +  commons-codec
> +  commons-codec
> +  1.3
> +
> +
>   
>  
>
>
>
>

[jira] Commented: (DIRMINA-489) Composite IoBuffer

[Mark Webb (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622025#action_12622025
 ] 

Mark Webb commented on DIRMINA-489:
---

I have checked in the code.  Please take a look and let me know what you think. 
 

Many thanks to Rich as I think he did a fantastic job with the code.  I only 
ran some sanity checks, formatted the code, javadoc'd the code and made sure it 
works with the latest trunk,



> Composite IoBuffer
> --
>
> Key: DIRMINA-489
> URL: https://issues.apache.org/jira/browse/DIRMINA-489
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: David M. Lloyd
>Assignee: Mark Webb
> Fix For: 2.0.0-M4
>
> Attachments: mina-composite-20080515.patch.gz, 
> mina-composite-20080517.patch, mina-composite-20080521-2.patch, 
> mina-composite-20080521.patch, mina-composite-20080723-1.patch, 
> mina-composite-20080723-2.patch
>
>
> Provide a way to create a large IoBuffer from several smaller IoBuffers, 
> without copying the underlying data.
> It would probably be acceptable to constrain the composite buffer in various 
> ways, for example by disallowing autoexpanding or otherwise changing the 
> capacity, the implementation could be greatly simplified.
> The goal is to be able to process large messages with a minimum of copying.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-616) New release.xml file

[Barend Garvelink (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barend Garvelink updated DIRMINA-616:
-

Attachment: release.xml

Attachment: updated release.xml file.



> New release.xml file
> 
>
> Key: DIRMINA-616
> URL: https://issues.apache.org/jira/browse/DIRMINA-616
> Project: MINA
>  Issue Type: Improvement
>Reporter: Barend Garvelink
> Attachments: release.xml
>
>
> In response to http://markmail.org/message/fhjl74dnlyaojrzr , here's an 
> updated release.xml file. 
> It generally works as it should, but it's affected by 
> http://jira.codehaus.org/browse/MASSEMBLY-285, which causes duplicate entries 
> in the lib/ directory inside the archive. When extracting the archive using 
> 7zip for win32, I get prompted to overwrite/skip/cancel for each duplicate 
> entry. Other archivers may file entirely (?). The only work-around I can come 
> up with as a fix right now is to add a maven-antrun-plugin to the package 
> phase of the root pom which post-processes the release file to fix this. I 
> haven't done that, but if MASSEMBLY-285 isn't fixed before the next release, 
> we may have to.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-616) New release.xml file

[Barend Garvelink (JIRA)]

New release.xml file


 Key: DIRMINA-616
 URL: https://issues.apache.org/jira/browse/DIRMINA-616
 Project: MINA
  Issue Type: Improvement
Reporter: Barend Garvelink


In response to http://markmail.org/message/fhjl74dnlyaojrzr , here's an updated 
release.xml file. 

It generally works as it should, but it's affected by 
http://jira.codehaus.org/browse/MASSEMBLY-285, which causes duplicate entries 
in the lib/ directory inside the archive. When extracting the archive using 
7zip for win32, I get prompted to overwrite/skip/cancel for each duplicate 
entry. Other archivers may file entirely (?). The only work-around I can come 
up with as a fix right now is to add a maven-antrun-plugin to the package phase 
of the root pom which post-processes the release file to fix this. I haven't 
done that, but if MASSEMBLY-285 isn't fixed before the next release, we may 
have to.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DIRMINA-615) Improved support for custom NioProcessors

[Julien Vermillard (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julien Vermillard closed DIRMINA-615.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-M4
 Assignee: Julien Vermillard

applied, thanks

> Improved support for custom NioProcessors
> -
>
> Key: DIRMINA-615
> URL: https://issues.apache.org/jira/browse/DIRMINA-615
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Reporter: Barend Garvelink
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M4
>
> Attachments: CustomNioProcessor.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> This patch improves support for using custom NioProcessors by making the 
> NioProcessor class non-final, and exposing two more of AbstractIoProcessor's 
> constructors in NioDatagramConnector and NioSocketConnector. This patch 
> originates from the problem described here: 
> http://markmail.org/message/jhjzybwosovbfetu , but it's much more elegant 
> than the change I originally thought of.
> Patch is based on SVN revision 685233. All of 
> http://svn.apache.org/repos/asf/mina/trunk still compiles and passes its unit 
> tests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Download page and structures of release tarballs

[W.B. Garvelink]

I'm halfway through changing release.xml for this. I'll submit a patch
later tonight.


Barend





On Tue, Aug 12, 2008 at 9:03 PM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 12, 2008 at 5:07 PM, Julien Vermillard
> <[EMAIL PROTECTED]> wrote:
>> I would like to propose something different :
>>  - a "binaries" directory for .jar binaries
>>  - a "sources" directory for sources of all the modules and with the
>> pom.xml files for building with maven
>>  - a "docs" directory for docs (javadoc and xref)
>>  - licences & notices in root directory
>
> How about doing separate binary and source tarballs?
>
>> We still miss :
>>  - a "lib" directory for all the dependencies (anyone know how to do
>> that with automagicly with mvn ?)
>
> You can check how I did it for FtpServer, as Barend suggested below I
> use the maven-assembly-plugin.
>
>>  - RATS report for Niklas :)
>
> Woho! Again, feel free to use what I've done in FtpServer.
>
> /niklas
>

Re: Download page and structures of release tarballs

[Niklas Gustavsson]

On Tue, Aug 12, 2008 at 5:07 PM, Julien Vermillard
<[EMAIL PROTECTED]> wrote:
> I would like to propose something different :
>  - a "binaries" directory for .jar binaries
>  - a "sources" directory for sources of all the modules and with the
> pom.xml files for building with maven
>  - a "docs" directory for docs (javadoc and xref)
>  - licences & notices in root directory

How about doing separate binary and source tarballs?

> We still miss :
>  - a "lib" directory for all the dependencies (anyone know how to do
> that with automagicly with mvn ?)

You can check how I did it for FtpServer, as Barend suggested below I
use the maven-assembly-plugin.

>  - RATS report for Niklas :)

Woho! Again, feel free to use what I've done in FtpServer.

/niklas

[jira] Commented: (DIRMINA-489) Composite IoBuffer

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621928#action_12621928
 ] 

Julien Vermillard commented on DIRMINA-489:
---

today I was digging in old asyncweb codebase because at the time it was using 
some streams & byte arrays as HttpMessage contents and not IoBuffer. Here a 
link to the implementation : 
https://svn.safehaus.org/repos/asyncweb/branches/asyncweb-codefreeze-02132006/src/org/safehaus/asyncweb/io/
 (mainly Bytes.java and BytesOutputStream.java). Perhaps it can give some 
inspiration :)

> Composite IoBuffer
> --
>
> Key: DIRMINA-489
> URL: https://issues.apache.org/jira/browse/DIRMINA-489
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: David M. Lloyd
>Assignee: Mark Webb
> Fix For: 2.0.0-M4
>
> Attachments: mina-composite-20080515.patch.gz, 
> mina-composite-20080517.patch, mina-composite-20080521-2.patch, 
> mina-composite-20080521.patch, mina-composite-20080723-1.patch, 
> mina-composite-20080723-2.patch
>
>
> Provide a way to create a large IoBuffer from several smaller IoBuffers, 
> without copying the underlying data.
> It would probably be acceptable to constrain the composite buffer in various 
> ways, for example by disallowing autoexpanding or otherwise changing the 
> capacity, the implementation could be greatly simplified.
> The goal is to be able to process large messages with a minimum of copying.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Download page and structures of release tarballs

[W.B. Garvelink]

On Tue, Aug 12, 2008 at 5:07 PM, Julien Vermillard
<[EMAIL PROTECTED]> wrote:
> We still miss :
> - [...]
>  - a "lib" directory for all the dependencies (anyone know how to do
> that with automagicly with mvn ?)

- Using maven-assembly-plugin: add a DependencySet element to release.xml.
- Using maven-dependency-plugin: use the copy-dependencies task.

I'd recommend the former.

Barend

[jira] Created: (DIRMINA-615) Improved support for custom NioProcessors

[Barend Garvelink (JIRA)]

Improved support for custom NioProcessors
-

 Key: DIRMINA-615
 URL: https://issues.apache.org/jira/browse/DIRMINA-615
 Project: MINA
  Issue Type: Improvement
  Components: Core
Reporter: Barend Garvelink
 Attachments: CustomNioProcessor.patch

This patch improves support for using custom NioProcessors by making the 
NioProcessor class non-final, and exposing two more of AbstractIoProcessor's 
constructors in NioDatagramConnector and NioSocketConnector. This patch 
originates from the problem described here: 
http://markmail.org/message/jhjzybwosovbfetu , but it's much more elegant than 
the change I originally thought of.

Patch is based on SVN revision 685233. All of 
http://svn.apache.org/repos/asf/mina/trunk still compiles and passes its unit 
tests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-615) Improved support for custom NioProcessors

[Barend Garvelink (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barend Garvelink updated DIRMINA-615:
-

Attachment: CustomNioProcessor.patch

Attachment: patch file for this improvement.

> Improved support for custom NioProcessors
> -
>
> Key: DIRMINA-615
> URL: https://issues.apache.org/jira/browse/DIRMINA-615
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Reporter: Barend Garvelink
> Attachments: CustomNioProcessor.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> This patch improves support for using custom NioProcessors by making the 
> NioProcessor class non-final, and exposing two more of AbstractIoProcessor's 
> constructors in NioDatagramConnector and NioSocketConnector. This patch 
> originates from the problem described here: 
> http://markmail.org/message/jhjzybwosovbfetu , but it's much more elegant 
> than the change I originally thought of.
> Patch is based on SVN revision 685233. All of 
> http://svn.apache.org/repos/asf/mina/trunk still compiles and passes its unit 
> tests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Download page and structures of release tarballs

[Mark Webb]

sounds good to me.

+1 to organization :)

On Tue, Aug 12, 2008 at 11:07 AM, Julien Vermillard
<[EMAIL PROTECTED]>wrote:

> Hi,
>
> I updated a bit the download page :
> http://mina.apache.org/downloads.html
> I hope it less confusing about downloading and signature checking.
> Feedback welcome!
>
> Secondly, our current release tarballs are quite messy, you got sources
> and binaries jar in the root, and you got sources in each sub modules
> directory, for an examples :
> http://mina.apache.org/dyn/closer.cgi/mina/2.0.0-M3/mina-2.0.0-M3.tar.bz2
>
> I would like to propose something different :
>  - a "binaries" directory for .jar binaries
>  - a "sources" directory for sources of all the modules and with the
> pom.xml files for building with maven
>  - a "docs" directory for docs (javadoc and xref)
>  - licences & notices in root directory
>
> Here an example :
> http://people.apache.org/~jvermillard/mina-2.0.0-M4-SNAPSHOT.tar.bz2
>
> We still miss :
>  - a good README.txt file
>  - a "lib" directory for all the dependencies (anyone know how to do
> that with automagicly with mvn ?)
>  - RATS report for Niklas :)
>
> WDYT ?
>
> Julien
>

Download page and structures of release tarballs

[Julien Vermillard]

Hi,

I updated a bit the download page :
http://mina.apache.org/downloads.html
I hope it less confusing about downloading and signature checking.
Feedback welcome! 

Secondly, our current release tarballs are quite messy, you got sources
and binaries jar in the root, and you got sources in each sub modules
directory, for an examples :
http://mina.apache.org/dyn/closer.cgi/mina/2.0.0-M3/mina-2.0.0-M3.tar.bz2

I would like to propose something different : 
 - a "binaries" directory for .jar binaries
 - a "sources" directory for sources of all the modules and with the
pom.xml files for building with maven
 - a "docs" directory for docs (javadoc and xref)
 - licences & notices in root directory

Here an example :
http://people.apache.org/~jvermillard/mina-2.0.0-M4-SNAPSHOT.tar.bz2

We still miss :
  - a good README.txt file
  - a "lib" directory for all the dependencies (anyone know how to do
that with automagicly with mvn ?)
  - RATS report for Niklas :)

WDYT ?

Julien


signature.asc
Description: PGP signature

[jira] Created: (FTPSERVER-152) NativeFileObject.hasDeletePermission() not working as expected.

[David Latorre (JIRA)]

NativeFileObject.hasDeletePermission()  not working as expected.


 Key: FTPSERVER-152
 URL: https://issues.apache.org/jira/browse/FTPSERVER-152
 Project: FtpServer
  Issue Type: Bug
Affects Versions: 1.0-M2, 1.0-M3
Reporter: David Latorre
 Fix For: 1.0-M2



In the current implementation, "hasDeletePermission" in NativeFileObject 
delegates to hasWritePermission in order to check whether a file can be deleted 
or not. But, in most environments, a file can be deleted when it is parent 
directory is writable, no matter if the file is writable itself or not. I 
attach a fix which attempts to preserve both options: it will check FTPServer's 
write permission for the actual file and if its parent directory is writable.

 public boolean hasDeletePermission() {

// root cannot be deleted
if ("/".equals(fileName)) {
return false;
}

/*  Added 12/08/2008: in the case that the permission is not explicitly 
denied for this file
 *  we will check if the parent file has write permission as most 
systems consider that a file can 
 *  be deleted when their parent directory is writable.
*/
String fullName=getFullName();

// we check FTPServer's write permission for this file.
if (user.authorize(new WriteRequest(fullName)) == null) {
return false;
}  
// In order to mantain consistency, when possible we delete the last 
'/' character in the String
int indexOfSlash=fullName.lastIndexOf('/');
String parentFullName;
if (indexOfSlash==0){
parentFullName="/";
}
else{
parentFullName=fullName.substring(0,indexOfSlash);
}

// we check if the parent FileObject is writable.
NativeFileObject parentObject=new 
NativeFileObject(parentFullName,file.getAbsoluteFile().getParentFile(),user);
return parentObject.hasWritePermission();
}

 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.