I don't see anything here that attempts to block, and not sure why you
are creating a new file object.
I was thinking of something along the lines of:
if ( isCollection() && inputContext.hasStream() ) // New File
{
if ( exists ) {
throw new DavException( HttpServletResponse.SC_FORBIDDEN, "You
can't overwrite resources already in the repository" );
}
...
With a more descriptive error message and a configuration check.
Cheers,
Brett
On 24/03/2009, at 10:39 AM, <[email protected]> wrote:
Here is a simple modification I have made to block duplicate
deployments. Any idea what I could be missing because it is not
working
properly. This is in the addMember method.
if ( isCollection() && inputContext.hasStream() ) // New File
{
File file = null;
FileOutputStream stream =
null;
try
{
file = new
File(localFile.toString());
if (!file.exists()){
System.out.println("
does not EXIST..." +localFile.toString());
stream = new
FileOutputStream( localFile );
IOUtils.copy(
inputContext.getInputStream(), stream ); //takes in one file & then
sends it. send another one after this
}
}
// catch ( IOException e )
catch ( Exception e )
{
throw new DavException(
HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e );
}
-----Original Message-----
From: Brett Porter [mailto:[email protected]]
Sent: 23 March 2009 23:34
To: [email protected]
Subject: Re: archiva source code
Not quite sure what you are referring to... addMember takes an
inputContext with a stream - the servlet container and jackrabbit
handle taking this directly from the client and passing in a stream
that is written to the localFile.
What you want to do is, based on the value of exists and the new
configuration option, fail.
Cheers,
Brett
On 24/03/2009, at 10:29 AM, <[email protected]> wrote:
Hi again,
I have just started having a go at fixing the issue below. Before
archiva starts copying artifacts to the version directory, 1.e., 4.1,
9.0, 1.2.3 and so on...., it creates it somewhere first. Does anyone
have an idea where? I have commented out the 'addMember' method in
the
'ArchivaDavResource' class and this confirms that the version
directory
is not created there. Does anyone know where it is created? If I can
find the answer to this, then the rest should be trivial.
Thanks.
-----Original Message-----
From: Brett Porter [mailto:[email protected]] On Behalf Of Brett
Porter
Sent: 17 March 2009 10:07
To: [email protected]
Subject: Re: archiva source code
On 17/03/2009, at 8:57 PM, <[email protected]>
<[email protected]
wrote:
The problem is that Archiva accepts deployments of artifacts that
already exist in the repository. I have already modified the code in
the
UploadAction class to block off any duplicates via the upload
section on
the Archiva UI and now I am trying to do the same for Webdav. I am
open
for suggestions if anyone has some, because it seems like doing the
same
for deployments via Webdav is going to be a tough hack.
ArchivaDavResource has an addMember resource that takes care of this,
so you can make the modification there.
If you are able to also add some configuration on the managed
repository as to whether it should allow this or not, this would be a
great change to contribute back. Will you be able to submit a patch
for your changes?
Cheers,
Brett
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking
action
on the basis of information in this e-mail and must delete all
copies.
Nomura will not accept responsibility or liability for the accuracy
or
completeness of, or the presence of any virus or disabling code in,
this
e-mail. If verification is sought please request a hard copy. Any
reference
to the terms of executed transactions should be treated as
preliminary only
and subject to formal written confirmation by Nomura. Nomura
reserves the
right to monitor e-mail communications through its networks (in
accordance
with applicable laws). No confidentiality or privilege is waived or
lost by
Nomura by any mistransmission of this e-mail. Any reference to
"Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please
read
our Electronic Communications Legal Notice which forms part of this
e-mail:
http://www.Nomura.com/email_disclaimer.htm
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking
action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in,
this
e-mail. If verification is sought please request a hard copy. Any
reference
to the terms of executed transactions should be treated as
preliminary only
and subject to formal written confirmation by Nomura. Nomura
reserves the
right to monitor e-mail communications through its networks (in
accordance
with applicable laws). No confidentiality or privilege is waived or
lost by
Nomura by any mistransmission of this e-mail. Any reference to
"Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please
read
our Electronic Communications Legal Notice which forms part of this
e-mail:
http://www.Nomura.com/email_disclaimer.htm
--
Brett Porter
[email protected]
http://blogs.exist.com/bporter/
