from:"Oliver Zeigermann"

[
https://issues.apache.org/jira/browse/TRANSACTION-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512556
]

Oliver Zeigermann commented on TRANSACTION-16:
--

I have now tried to set up new landmarks for commons transaction 2.0. All Java
5 features, including Generics and the concurrent package are allowed now.

Dennis, could you try and see where your work could fit in? Especially,
considering the new internal TransactionManager, LockManager and LockPolicy.

Does this make sense to you in the first place?

Oliver

TX collections / TX object model

Key: TRANSACTION-16
URL: https://issues.apache.org/jira/browse/TRANSACTION-16
Project: Commons Transaction
Issue Type: Wish
Reporter: Dennis Thrysøe
Assignee: Oliver Zeigermann
Attachments: buzz.zip

(Quoted from the original message:
http://marc.info/?l=jakarta-commons-devm=118129603213307w=4):
I would like to donate an implementation of some transaction enabled
collections and resources.
The implementation is (more or less) JTA compliant, and mostly finished. It
is not well-tested, robust or mature.
The code includes:
1) TX collections: Map, Set and List wrappers for transactional
protection/isolation. Supported nested collections such that for instance a
List or Set in a transactional Map is wrapped in the appropriate wrapper.
Copy-on-tx-start and locking.
2) TX object model: An object is passed to the wrapper and after that only
used when retrieved from the wrapper. The object is wrapped in a dynamic
proxy which makes sure all returned objects from reachable instances are also
wrapped. Copy-on-write and locking. I have some additional ideas on this one.
-
I hereby donate the attached source code for inclusion in or inspiration for
commons-transaction.
I will be happy to participate further in the development of these features.
Some of the stuff in the project can be considered experimental, and not yet
done, but most is fully implemented.
-dennis

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRANSACTION-15) Lightweight transaction leaks on exception from FileResourceManager.getResource


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

Oliver Zeigermann resolved TRANSACTION-15.
--

Resolution: Won't Fix

Lighweight transactions were a really bad idea. Please avoid them. There will 
be no equivalent for them in 2.0.

 Lightweight transaction leaks on exception from 
 FileResourceManager.getResource
 ---

 Key: TRANSACTION-15
 URL: https://issues.apache.org/jira/browse/TRANSACTION-15
 Project: Commons Transaction
  Issue Type: Bug
Affects Versions: 1.1, 1.2
 Environment: Current trunk of rev 542554
Reporter: Antranig Basman
Assignee: Oliver Zeigermann
 Attachments: patch.txt, transaction-lightweight-fix.txt


 FileResourceManager getResource(String) method will leak in the case an 
 exception occurs during execution, in the most obvious case where the 
 resource does not exist. This is because the method does not do proper 
 cleanup of the lightweight transaction (which it allocated itself).
 Lightweight transactions in general are pretty sketchy in commons-transaction 
 which I think is a fact that should be advertised a bit more widely - I was a 
 little disappointed to see that the 1.2 release went ahead last month without 
 any more attention to the issues that I raised last May - the thread begins 
 22nd May 2006 at 
 http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL
  PROTECTED]
 (title: Memory leaks in GenericLockManager, FileResourceManager)
 The resolution to the leak I posted there was demonstrated not completely 
 sound, but I think in the absence of any other approach it would be better 
 than nothing - better that a heavyweight transaction immediately retried with 
 the same ID will very rarely fail than that every lightweight transaction 
 will leak :P
 In any case, this issue is more serious in that it is not just a leak, but 
 will permanently lock a part of the resource tree for the lifetime of the 
 ResourceManager. I have attached diffs for a patch and a test case for this 
 issue below.

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512561
]

Oliver Zeigermann commented on TRANSACTION-9:
-

I have tried to define a new interface that now supports folders. It is
supposed to go into the 2.0 release. I wll attach it. It does not define access
to any sort of meta data as this seems to be beyond the scope of the
implementation though. This rather is a CMS feature?

Do you agree?

[transaction] Add full file management capabilities to the FileResourceManager
--

Attachments: filemanager.zip, FileResourceManager.java

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

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

Oliver Zeigermann updated TRANSACTION-9:

Attachment: FileResourceManager.java

[transaction] Add full file management capabilities to the FileResourceManager
--

Attachments: filemanager.zip, FileResourceManager.java

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-11) Improve relationship between ResourceManager and FileResourceManager


[ 
https://issues.apache.org/jira/browse/TRANSACTION-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512566
 ] 

Oliver Zeigermann commented on TRANSACTION-11:
--

Is this still valid for 2.0?

 Improve relationship between ResourceManager and FileResourceManager
 

 Key: TRANSACTION-11
 URL: https://issues.apache.org/jira/browse/TRANSACTION-11
 Project: Commons Transaction
  Issue Type: Improvement
Affects Versions: 1.1
Reporter: Jeremy Fujimoto-Johnson
Assignee: Jörg Heinicke
 Fix For: 2.0

 Attachments: commons-transaction-rm-patch.txt


 Add the reset method to ResourceManager so that classes using a 
 ResourceManager won't have to cast it to FileResourceManager to call this 
 method.
 Add new constructors to FileResourceManager so that it can be constructed 
 with the default timeout period for transactions already specified so that 
 you don't have to cast to FileResourceManager to set it later.

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-14) Separate transaction handling from resource handling (split ResourceManager interface)


[ 
https://issues.apache.org/jira/browse/TRANSACTION-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512565
 ] 

Oliver Zeigermann commented on TRANSACTION-14:
--

For 2.0 I have tried to delegate each functionality to different interfaces 
now. There is one for FileResourceManager and one for TransactionManager. 
Additionally, there is a configurable locking strategy.

Does that seem reasonable?

 Separate transaction handling from resource handling (split ResourceManager 
 interface)
 --

 Key: TRANSACTION-14
 URL: https://issues.apache.org/jira/browse/TRANSACTION-14
 Project: Commons Transaction
  Issue Type: Improvement
Reporter: Jörg Heinicke
Assignee: Oliver Zeigermann
 Fix For: 2.0


 http://marc.theaimsgroup.com/?t=11528064431r=1w=4

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

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

Oliver Zeigermann updated TRANSACTION-9:

Attachment: (was: FileResourceManager.java)

[transaction] Add full file management capabilities to the FileResourceManager
--

Attachments: filemanager.zip

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager


[ 
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512652
 ] 

Oliver Zeigermann commented on TRANSACTION-9:
-

This is my proposal

public interface FileResourceManager {

boolean exists(String path) throws IOException, LockException;
boolean isFolder(String path) throws IOException, LockException;
boolean isFile(String path) throws IOException, LockException;
void createFolder(String folderpath) throws IOException, LockException;
void createFile(String path) throws IOException, LockException;
CollectionString getChildrenNames(String path) throws IOException, 
LockException;
public InputStream read(String path) throws IOException, LockException;
public OutputStream write(String path) throws IOException, LockException;
public boolean remove(String path) throws IOException, LockException;
public boolean move(String sourcepath, String destinationpath) throws 
IOException, LockException;
public boolean copy(String sourcepath, String destinationpath) throws 
IOException, LockException;
}

 [transaction] Add full file management capabilities to the FileResourceManager
 --

 Key: TRANSACTION-9
 URL: https://issues.apache.org/jira/browse/TRANSACTION-9
 Project: Commons Transaction
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: All
Reporter: Peter Fassev
Assignee: Oliver Zeigermann
Priority: Minor
 Fix For: 2.0

 Attachments: filemanager.zip


 Hi,
 As stated in the doc the FileResourceManager is:
 A resource manager for streamable objects stored in a file system
 I agree, that this is a resource manager, but it could be easily extended, to 
 support a full file management system. It will be very helpful to have 
 additional methods like renameResource(), getResourceSize(), 
 getResourceTime(), 
 setResourceTime() etc. This are common file operations, which should be 
 managed 
 by the FileResourceManager.
 Further it will be very helpful to have (real) support for resource 
 collections 
 (folders). It will be necessary to distinguish between single resources 
 (files) 
 and collections (folders). 
 Together, this features will enable a transactional access to any file based 
 resources - for instance a document repository.
 Are there plans for such extensions and if not, will they actually fit in the 
 goals of the transaction library?
 If not, please open the underlying structure, like the inner class 
 TransactionContext, in order to add extensions the file management. For 
 instance, it will be good to have a separate factory method, which creates 
 the 
 context.
 If you are interested in this proposal, I am ready to contribute to this 
 project. I consider myself as an experienced java developer and I will be 
 glad 
 to help you. 
 Best regards
 Peter Fassev

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRANSACTION-19) applyDeletes method does not delete dangling links

2007-07-07 Thread Oliver Zeigermann (JIRA)


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

Oliver Zeigermann resolved TRANSACTION-19.
--

Resolution: Fixed

OK. Got that now. Thanks for the patch, it has been applied!

Oliver

 applyDeletes method does not delete dangling links
 --

 Key: TRANSACTION-19
 URL: https://issues.apache.org/jira/browse/TRANSACTION-19
 Project: Commons Transaction
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Linux CentOS, Java 1.5
Reporter: Bojan Vukojevic
Assignee: Oliver Zeigermann

 applyDeletes method will not delete any dangling links. Even if the link was 
 valid, code may run into this situation if the file is passed to be deleted 
 before link is registered for deletion. Code will delete the file 
 effectivelly creating a dangling link that will  not be deleted. 
 The fix might be another change to applyDeletes method i.e. something like:
 protected static void applyDeletes(File removeDir, File targetDir, File 
 rootDir) throws IOException {
 if (removeDir.isDirectory()  targetDir.isDirectory()) {
 File[] files = removeDir.listFiles();
 for (int i = 0; i  files.length; i++) {
 File removeFile = files[i];
 File targetFile = new File(targetDir, removeFile.getName());
 if (!removeFile.isDirectory()) {
 if (targetFile.exists()) {
 if (!targetFile.delete()) {
 throw new IOException(Could not delete file  + 
 removeFile.getName()
 +  in directory targetDir);
 }
 } else if(!targetFile.isFile()){  // CHANGE 
 to delete dangling link=
   //this is likely a dangling link
   targetFile.delete();  
 }
 // indicate, this has been done
 removeFile.delete();
 } else {
 applyDeletes(removeFile, targetFile, rootDir);
 }
 // delete empty target directories, except root dir
 if (!targetDir.equals(rootDir)  targetDir.list().length == 
 0) {
 targetDir.delete();
 }
 }
 }
 }

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

InputStream-Multicaster

2007-06-21 Thread Oliver Zeigermann


Folks!

Do we have a component that contains an implementation for an
InputStream multicast. What I am mean is something that takes an
InputStream and makes it available to many consumers at the same time.
This would require threading and concurrency of course.

If no, which component would be suitable to host such an implementation.

Thanks in advance and cheers

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRANSACTION-18) applyDeletes method does not delete symbolic links

2007-06-15 Thread Oliver Zeigermann (JIRA)


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

Oliver Zeigermann resolved TRANSACTION-18.
--

Resolution: Fixed

Fixed by applying your patch. Thansk :)

 applyDeletes method does not delete symbolic links
 --

 Key: TRANSACTION-18
 URL: https://issues.apache.org/jira/browse/TRANSACTION-18
 Project: Commons Transaction
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Linux CENT OS
Reporter: Bojan Vukojevic
Assignee: Oliver Zeigermann

 applyDeletes static method in FileResourceManager (line 154) checks isFile 
 and if this returns false assumes it is a directory. This fails if the 
 resource is symbolic link. Instead, it should call isDirectory and then 
 recursively call itself, otherwise, it should delete the resource.
 The fix is shown below:
 protected static void applyDeletes(File removeDir, File targetDir, File 
 rootDir) throws IOException {
 if (removeDir.isDirectory()  targetDir.isDirectory()) {
 File[] files = removeDir.listFiles();
 for (int i = 0; i  files.length; i++) {
 File removeFile = files[i];
 File targetFile = new File(targetDir, removeFile.getName());
 if (!removeFile.isDirectory()) {  //===THIS IS THE 
 FIX - WAS removeFile.isFile===
 if (targetFile.exists()) {
 if (!targetFile.delete()) {
 throw new IOException(Could not delete file  + 
 removeFile.getName()
 +  in directory targetDir);
 }
 }
 // indicate, this has been done
 removeFile.delete();
 } else {
 applyDeletes(removeFile, targetFile, rootDir);
 }
 // delete empty target directories, except root dir
 if (!targetDir.equals(rootDir)  targetDir.list().length == 
 0) {
 targetDir.delete();
 }
 }
 }
 }

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-19) applyDeletes method does not delete dangling links

2007-06-15 Thread Oliver Zeigermann (JIRA)


[ 
https://issues.apache.org/jira/browse/TRANSACTION-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505371
 ] 

Oliver Zeigermann commented on TRANSACTION-19:
--

I can quite follow you here, though I am sure there is substance to what you 
have. Could you give an example scenario to explain? Thanks in advance!

 applyDeletes method does not delete dangling links
 --

 Key: TRANSACTION-19
 URL: https://issues.apache.org/jira/browse/TRANSACTION-19
 Project: Commons Transaction
  Issue Type: Bug
Affects Versions: 1.2
 Environment: Linux CentOS, Java 1.5
Reporter: Bojan Vukojevic
Assignee: Oliver Zeigermann

 applyDeletes method will not delete any dangling links. Even if the link was 
 valid, code may run into this situation if the file is passed to be deleted 
 before link is registered for deletion. Code will delete the file 
 effectivelly creating a dangling link that will  not be deleted. 
 The fix might be another change to applyDeletes method i.e. something like:
 protected static void applyDeletes(File removeDir, File targetDir, File 
 rootDir) throws IOException {
 if (removeDir.isDirectory()  targetDir.isDirectory()) {
 File[] files = removeDir.listFiles();
 for (int i = 0; i  files.length; i++) {
 File removeFile = files[i];
 File targetFile = new File(targetDir, removeFile.getName());
 if (!removeFile.isDirectory()) {
 if (targetFile.exists()) {
 if (!targetFile.delete()) {
 throw new IOException(Could not delete file  + 
 removeFile.getName()
 +  in directory targetDir);
 }
 } else if(!targetFile.isFile()){  // CHANGE 
 to delete dangling link=
   //this is likely a dangling link
   targetFile.delete();  
 }
 // indicate, this has been done
 removeFile.delete();
 } else {
 applyDeletes(removeFile, targetFile, rootDir);
 }
 // delete empty target directories, except root dir
 if (!targetDir.equals(rootDir)  targetDir.list().length == 
 0) {
 targetDir.delete();
 }
 }
 }
 }

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-17) MultipartStream public API broken

2007-06-14 Thread Oliver Zeigermann (JIRA)


[ 
https://issues.apache.org/jira/browse/TRANSACTION-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504716
 ] 

Oliver Zeigermann commented on TRANSACTION-17:
--

Hi Mark!

Are you sure that you are talking about commons transaction here? I can not 
find class MultipartStream in this component. Maybe you wanted to refer to the 
fileupload component?!

 MultipartStream public API broken
 -

 Key: TRANSACTION-17
 URL: https://issues.apache.org/jira/browse/TRANSACTION-17
 Project: Commons Transaction
  Issue Type: Bug
 Environment: commons-transaction version 1.2
Reporter: Mark Sinke

 In commons-transaction 1.2 the MultipartStream class has 2 public 
 constructors. Both are deprecated; however their implementation delegates to 
 non-visible (package-private) constructors. There are two issues here:
 1. the deprecated, delegating constructors use a null pointer for the 
 progress notifier, which in turn yield a NullPointerException when you try to 
 use them
 2. the non-deprecated constructors are not visible.
 Hence, I cannot really upgrade from 1.0 to 1.2.
 Thanks,
 Mark.

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRANSACTION-17) MultipartStream public API broken

2007-06-14 Thread Oliver Zeigermann (JIRA)


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

Oliver Zeigermann resolved TRANSACTION-17.
--

Resolution: Invalid

Setting to invalid for now.

 MultipartStream public API broken
 -

 Key: TRANSACTION-17
 URL: https://issues.apache.org/jira/browse/TRANSACTION-17
 Project: Commons Transaction
  Issue Type: Bug
 Environment: commons-transaction version 1.2
Reporter: Mark Sinke

 In commons-transaction 1.2 the MultipartStream class has 2 public 
 constructors. Both are deprecated; however their implementation delegates to 
 non-visible (package-private) constructors. There are two issues here:
 1. the deprecated, delegating constructors use a null pointer for the 
 progress notifier, which in turn yield a NullPointerException when you try to 
 use them
 2. the non-deprecated constructors are not visible.
 Hence, I cannot really upgrade from 1.0 to 1.2.
 Thanks,
 Mark.

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-16) TX collections / TX object model

2007-06-11 Thread Oliver Zeigermann (JIRA)


[ 
https://issues.apache.org/jira/browse/TRANSACTION-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503436
 ] 

Oliver Zeigermann commented on TRANSACTION-16:
--

Cool. That fits into ctx's picture. 

Maybe this could even be a starting point for the 2.0 version. 

Would you be willing to participate in further discussion and refactoring of 
your code?

 TX collections / TX object model
 

 Key: TRANSACTION-16
 URL: https://issues.apache.org/jira/browse/TRANSACTION-16
 Project: Commons Transaction
  Issue Type: Wish
Reporter: Dennis Thrysøe
Assignee: Oliver Zeigermann
 Attachments: buzz.zip


 I hereby donate the attached source code for inclusion in or inspiration for 
 commons-transaction.
 I will be happy to participate further in the development of these features.
 Some of the stuff in the project can be considered experimental, and not yet 
 done, but most is fully implemented.
 -dennis

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-16) Code donation

2007-06-08 Thread Oliver Zeigermann (JIRA)


[ 
https://issues.apache.org/jira/browse/TRANSACTION-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502929
 ] 

Oliver Zeigermann commented on TRANSACTION-16:
--

I had a look at the code and it looks interesting. However, I am not sure if I 
understand how and which parts you would want to share / merge into commons 
transactions. Any idea how this might fit?

I also notice that you use generics which requires at least JDK 1.5. 

Commons transaction 2.0 which is currently in its planing phase will require at 
least JDK 1.5, maybe even 1.6. So this might be a better match. 

Do you see how your code could fit into ctx 2.0?

Here is the 2.0 Wiki-Link: 
http://wiki.apache.org/jakarta-commons/Brainstorm_Transaction_2%2e0



 Code donation
 -

 Key: TRANSACTION-16
 URL: https://issues.apache.org/jira/browse/TRANSACTION-16
 Project: Commons Transaction
  Issue Type: Wish
Reporter: Dennis Thrysøe
 Attachments: buzz.zip


 I hereby donate the attached source code for inclusion in or inspiration for 
 commons-transaction.
 I will be happy to participate further in the development of these features.
 Some of the stuff in the project can be considered experimental, and not yet 
 done, but most is fully implemented.
 -dennis

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (TRANSACTION-15) Lightweight transaction leaks on exception from FileResourceManager.getResource

2007-06-08 Thread Oliver Zeigermann (JIRA)


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

Oliver Zeigermann updated TRANSACTION-15:
-

Attachment: patch.txt

As far as I can see your patch only has a suggestion for the removal of unused 
owners. As discussed in the thread you state this may fail in certain scenarios 
where another thread adds a new log for that specific owner. That is possible 
as in common tx you can have more than one thread per owner (not really a good 
idea, though). 

My recent commit, shown in the patch, takes over your idea and tries to take 
the above argument into account.

Please check if that fixes the bug.

 Lightweight transaction leaks on exception from 
 FileResourceManager.getResource
 ---

 Key: TRANSACTION-15
 URL: https://issues.apache.org/jira/browse/TRANSACTION-15
 Project: Commons Transaction
  Issue Type: Bug
Affects Versions: 1.1, 1.2
 Environment: Current trunk of rev 542554
Reporter: Antranig Basman
 Attachments: patch.txt, transaction-lightweight-fix.txt


 FileResourceManager getResource(String) method will leak in the case an 
 exception occurs during execution, in the most obvious case where the 
 resource does not exist. This is because the method does not do proper 
 cleanup of the lightweight transaction (which it allocated itself).
 Lightweight transactions in general are pretty sketchy in commons-transaction 
 which I think is a fact that should be advertised a bit more widely - I was a 
 little disappointed to see that the 1.2 release went ahead last month without 
 any more attention to the issues that I raised last May - the thread begins 
 22nd May 2006 at 
 http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL
  PROTECTED]
 (title: Memory leaks in GenericLockManager, FileResourceManager)
 The resolution to the leak I posted there was demonstrated not completely 
 sound, but I think in the absence of any other approach it would be better 
 than nothing - better that a heavyweight transaction immediately retried with 
 the same ID will very rarely fail than that every lightweight transaction 
 will leak :P
 In any case, this issue is more serious in that it is not just a leak, but 
 will permanently lock a part of the resource tree for the lifetime of the 
 ResourceManager. I have attached diffs for a patch and a test case for this 
 issue below.

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-15) Lightweight transaction leaks on exception from FileResourceManager.getResource

2007-06-08 Thread Oliver Zeigermann (JIRA)


[ 
https://issues.apache.org/jira/browse/TRANSACTION-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502945
 ] 

Oliver Zeigermann commented on TRANSACTION-15:
--

Concerning your observations with light weight transactions I can only agree. 
They really are not very robust and have to be used with extreme care. 

I would like to see them fixed as well, but it is as easy as this: No patch, no 
fix ;)

As a workaround use full transactions. 

 Lightweight transaction leaks on exception from 
 FileResourceManager.getResource
 ---

 Key: TRANSACTION-15
 URL: https://issues.apache.org/jira/browse/TRANSACTION-15
 Project: Commons Transaction
  Issue Type: Bug
Affects Versions: 1.1, 1.2
 Environment: Current trunk of rev 542554
Reporter: Antranig Basman
Assignee: Oliver Zeigermann
 Attachments: patch.txt, transaction-lightweight-fix.txt


 FileResourceManager getResource(String) method will leak in the case an 
 exception occurs during execution, in the most obvious case where the 
 resource does not exist. This is because the method does not do proper 
 cleanup of the lightweight transaction (which it allocated itself).
 Lightweight transactions in general are pretty sketchy in commons-transaction 
 which I think is a fact that should be advertised a bit more widely - I was a 
 little disappointed to see that the 1.2 release went ahead last month without 
 any more attention to the issues that I raised last May - the thread begins 
 22nd May 2006 at 
 http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200605.mbox/[EMAIL
  PROTECTED]
 (title: Memory leaks in GenericLockManager, FileResourceManager)
 The resolution to the leak I posted there was demonstrated not completely 
 sound, but I think in the absence of any other approach it would be better 
 than nothing - better that a heavyweight transaction immediately retried with 
 the same ID will very rarely fail than that every lightweight transaction 
 will leak :P
 In any case, this issue is more serious in that it is not just a leak, but 
 will permanently lock a part of the resource tree for the lifetime of the 
 ResourceManager. I have attached diffs for a patch and a test case for this 
 issue below.

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [all] Going TLP?

2007-04-03 Thread Oliver Zeigermann


+1 to all said. I could even help.

-0 to waiting until we have a clear idea about the rest of Jakarta as
this is likely to never happen. Maybe a clearer idea will form after
commons leaves Jakarta.

Oliver

2007/4/3, Henri Yandell [EMAIL PROTECTED]:

On 4/2/07, Phil Steitz [EMAIL PROTECTED] wrote:
 On 4/2/07, Henri Yandell [EMAIL PROTECTED] wrote:

  So with that said - I'd like to propose that we move to commons.apache.org.
 

 +1
 We have talked about this lots of times before and some discussions
 have had us breaking commons itself apart into pieces.  My +1 is for
 the whole of commons as an Apache TLP.

 To answer some other questions that have come up before and will resurface:

 +1 for only Java components (flame away, this is just my HO)

Yep - though in reality this means:

We'll do whatever the community wants to do. If someone proposes a
Ruby library and we have a community interested in creating and
supporting a Ruby library, then it would of course be strongly
considered. 

The argument here is going to be in what we put in our resolution. Do
we explicitly state Java, or do we leave things language agnostic and
rely on the fact that it is our community, and generally our community
is going to want to do Java and Java related things.

 +1 for bringing sandbox along

And dormant.

 +1 for welcoming small components from other Jakarta subprojects

 +0 for waiting to do this until we have a clear idea of where the rest
 of the Jakarta subprojects are going.

Once we go TLP, I imagine a few would head in our direction, whereas
until we go TLP there won't  be much of a decision made either way. I
know I plan to suggest that the RDC taglib moves to Commons so it can
be with SCXML (they're fairly tied aren't they?), and then the other
parts of Taglibs can be put gently to sleep (unsure on JSTL).

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] New committer - Stephen Kestle

2007-03-21 Thread Oliver Zeigermann


+1

Oliver

2007/3/21, Stephen Colebourne [EMAIL PROTECTED]:

Stephen has spent a considerable amount of effort in discussions and
chivying in the commons area, particularly on commons-collections.

In another life he has been heavily involved in one of the existing
generics ports of collections - http://collections.sf.net.

[ ] +1 - Let him commit
[ ]  0
[ ] -1 - Perhaps not...

Stephen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] administration interface

2007-03-20 Thread Oliver Zeigermann


Right.

Option one (the delegating thing) could be the option of choice for
the 1.x branch. For 2.0 the JMX approach sounds like a much better
idea.

I will modify the code in the 1.x branch ASAP.

Would you please add the JMX approach to the 2.0 Wiki page as a cool idea?

Thanks for reporing and cheers

Oliver

2007/3/20, Joerg Heinicke [EMAIL PROTECTED]:

Oliver Zeigermann oliver.zeigermann at gmail.com writes:

 This code is to allow calling certain manager methods simply by
 accessing a certain path. It lacks a flexible configuration using a
 mapping from suffix to method to be called, though.

Hi Oliver,

to be honest this way of handling it frightens me a bit. On the one hand it adds
yet another concern and much code to the FileResourceManager, on the other hand
this choose an unlikely resource path as virtual admin path sounds a bit 
hacky.

Wouldn't it be better to externalize this feature? From what I see on a quick
look it should be easily possible to write a
VirtualAdminCommandsFileResourceManager wrapping the actual FileResourceManager
and delegating all calls to it after having filtered out the admin commands only
relevant for itself. Another option I'd consider would be something like JMX -
though I have never used it and don't know actually if it is appropriate.

Regards
Jörg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] administration interface

2007-03-20 Thread Oliver Zeigermann


Done.

2007/3/20, Oliver Zeigermann [EMAIL PROTECTED]:

Right.

Option one (the delegating thing) could be the option of choice for
the 1.x branch. For 2.0 the JMX approach sounds like a much better
idea.

I will modify the code in the 1.x branch ASAP.

Would you please add the JMX approach to the 2.0 Wiki page as a cool idea?

Thanks for reporing and cheers

Oliver

2007/3/20, Joerg Heinicke [EMAIL PROTECTED]:
 Oliver Zeigermann oliver.zeigermann at gmail.com writes:

  This code is to allow calling certain manager methods simply by
  accessing a certain path. It lacks a flexible configuration using a
  mapping from suffix to method to be called, though.

 Hi Oliver,

 to be honest this way of handling it frightens me a bit. On the one hand it 
adds
 yet another concern and much code to the FileResourceManager, on the other 
hand
 this choose an unlikely resource path as virtual admin path sounds a bit 
hacky.

 Wouldn't it be better to externalize this feature? From what I see on a quick
 look it should be easily possible to write a
 VirtualAdminCommandsFileResourceManager wrapping the actual 
FileResourceManager
 and delegating all calls to it after having filtered out the admin commands 
only
 relevant for itself. Another option I'd consider would be something like JMX -
 though I have never used it and don't know actually if it is appropriate.

 Regards
 Jörg


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCEMENT] Commons Transaction 1.2 Released

2007-03-18 Thread Oliver Zeigermann


Dear community!

Jakarta Commons Transaction 1.2 has been released. This is a bug
fix/maintenance/feature release of Commons Transaction. A lot of bug
fixing work from a number of people has gone into this release. This
makes Commons Transaction more stable and reliable. Additionally, some
nice features have been added.

Commons Transaction aims at providing utility classes commonly used in
transactional Java programming. There are implementations for multi
level (e.g. read/write) locks, transactional maps, and transactional
file access, plus some helper classes

Downloads:
http://jakarta.apache.org/site/downloads/downloads_commons-transaction.cgi

Release notes:
http://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/tags/TRANSACTION_1_2_RELEASE/RELEASE-NOTES.txt

Commons Transaction web site:
http://jakarta.apache.org/commons/transaction/

Oliver
(on behalf of the Jakarta community)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r519647 - in /jakarta/commons/proper/transaction/trunk/src: java/org/apache/commons/transaction/file/FileResourceManager.java test/org/apache/commons/transaction/file/FileResourceManag

2007-03-18 Thread Oliver Zeigermann


This code is to allow calling certain manager methods simply by
accessing a certain path. It lacks a flexible configuration using a
mapping from suffix to method to be called, though.

2007/3/18, [EMAIL PROTECTED] [EMAIL PROTECTED]:

Author: ozeigermann
Date: Sun Mar 18 10:50:02 2007
New Revision: 519647

URL: http://svn.apache.org/viewvc?view=revrev=519647
Log:
Added sketch for administration interface

Added:

jakarta/commons/proper/transaction/trunk/src/test/org/apache/commons/transaction/file/FileResourceManagerVirtualAdminCommandsTest.java
Modified:

jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java

Modified: 
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java?view=diffrev=519647r1=519646r2=519647
==
--- 
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
 (original)
+++ 
jakarta/commons/proper/transaction/trunk/src/java/org/apache/commons/transaction/file/FileResourceManager.java
 Sun Mar 18 10:50:02 2007
@@ -18,6 +18,7 @@

 import java.io.BufferedReader;
 import java.io.BufferedWriter;
+import java.io.ByteArrayInputStream;
 import java.io.File;
 import java.io.FileInputStream;
 import java.io.FileNotFoundException;
@@ -195,6 +196,8 @@
 protected TransactionIdToPathMapper txIdMapper = null;

 protected int idCnt = 0;
+
+protected String virtualAdminPath = null;

 /*
  * --- ctor and general getter / setter methods ---
@@ -202,6 +205,14 @@
  *
  */

+public String getVirtualAdminPath() {
+return virtualAdminPath;
+}
+
+public void setVirtualAdminPath(String virutalAdminPath) {
+this.virtualAdminPath = virutalAdminPath;
+}
+
 /**
  * Creates a new resource manager operation on the specified directories.
  *
@@ -717,16 +728,26 @@
 }

 public boolean resourceExists(Object txId, Object resourceId) throws 
ResourceManagerException {
+if (isVirtualAdminId(resourceId)) {
+logger.logFine(Faking existence of virtual administration 
command);
+return true;
+}
+
 lockResource(resourceId, txId, true);
 return (getPathForRead(txId, resourceId) != null);
 }

 public void deleteResource(Object txId, Object resourceId) throws 
ResourceManagerException {
+
+checkForVirtualAdminCommand(resourceId);
+
 deleteResource(txId, resourceId, true);
 }

 public void deleteResource(Object txId, Object resourceId, boolean 
assureOnly) throws ResourceManagerException {

+checkForVirtualAdminCommand(resourceId);
+
 if (logger.isFineEnabled()) logger.logFine(txId +  deleting  + 
resourceId);

 lockResource(resourceId, txId, false);
@@ -760,11 +781,16 @@
 }

 public void createResource(Object txId, Object resourceId) throws 
ResourceManagerException {
+
+checkForVirtualAdminCommand(resourceId);
+
 createResource(txId, resourceId, true);
 }

 public void createResource(Object txId, Object resourceId, boolean 
assureOnly) throws ResourceManagerException {

+checkForVirtualAdminCommand(resourceId);
+
 if (logger.isFineEnabled()) logger.logFine(txId +  creating  + 
resourceId);

 lockResource(resourceId, txId, false);
@@ -798,6 +824,10 @@
 }

 public void copyResource(Object txId, Object fromResourceId, Object 
toResourceId, boolean overwrite) throws ResourceManagerException {
+
+checkForVirtualAdminCommand(fromResourceId);
+checkForVirtualAdminCommand(toResourceId);
+
 if (logger.isFineEnabled()) logger.logFine(txId +  copying  + fromResourceId + 
 to  + toResourceId);

 lockResource(fromResourceId, txId, true);
@@ -825,6 +855,10 @@
 }

 public void moveResource(Object txId, Object fromResourceId, Object 
toResourceId, boolean overwrite) throws ResourceManagerException {
+
+checkForVirtualAdminCommand(fromResourceId);
+checkForVirtualAdminCommand(toResourceId);
+
 if (logger.isFineEnabled()) logger.logFine(txId +  moving  + fromResourceId + 
 to  + toResourceId);

 lockResource(fromResourceId, txId, false);
@@ -836,6 +870,12 @@
 }

 public InputStream readResource(Object resourceId) throws 
ResourceManagerException {
+
+if (isVirtualAdminId(resourceId)) {
+logger.logWarning(Issuing virtual admin command + resourceId);
+return executeAdminCommand(resourceId);
+}
+
 // create temporary light weight tx
 Object txId;
 synchronized (globalTransactions) {
@@ -855,6 +895,12 @@
 }

 public InputStream readResource(Object txId, Object

Re: [transaction] Brainstorming for 2.0

2007-03-12 Thread Oliver Zeigermann


I have now created a Wiki page for the 2.0 discussion:

http://wiki.apache.org/jakarta-commons/Brainstorm_2%2e0

2007/3/9, Oliver Zeigermann [EMAIL PROTECTED]:

Packae naming:

As discussed here

http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL 
PROTECTED]

it might be a good idea to have a new package name for the 2.x version.

I'd be +1 for that

Oliver

2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]:
 Folks!

 As explaining in my previous post, I have created a new TRANSACTION2
 branch to contain initial code, docs, etc. for a future 2.0 version of
 Commons Transaction.

 If you have ideas, suggestions, etc. please follow up to this post
 until we find a more suitable place for such a discussion.

 Open Questions (my suggestions in brackets):
 1.) Medium for discussion (Wiki? SVN?)
 2.) Library requirement (1.5 concurrent package?)
 3.) Minimum JDK Requirement (always the latest, i.e. 1.6)
 4.) Scope (all restricted as possible)
 5.) What else?

 Cheers

 Oliver




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Brainstorming for 2.0

2007-03-12 Thread Oliver Zeigermann


Right.

Thanks for reporting, Martin!

Changed to

http://wiki.apache.org/jakarta-commons/Brainstorm_Transaction_2%2e0

Oliver

2007/3/12, Martin Cooper [EMAIL PROTECTED]:

On 3/12/07, Oliver Zeigermann [EMAIL PROTECTED] wrote:

 I have now created a Wiki page for the 2.0 discussion:

 http://wiki.apache.org/jakarta-commons/Brainstorm_2%2e0


Not a particularly good page name, given that it's not scoped to
Transaction in a any way. It could apply equally well to any Commons
component heading for 2.0.

--
Martin Cooper


2007/3/9, Oliver Zeigermann [EMAIL PROTECTED]:
  Packae naming:
 
  As discussed here
 
 
 
http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL 
PROTECTED]
 
  it might be a good idea to have a new package name for the 2.x version.
 
  I'd be +1 for that
 
  Oliver
 
  2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]:
   Folks!
  
   As explaining in my previous post, I have created a new TRANSACTION2
   branch to contain initial code, docs, etc. for a future 2.0 version of
   Commons Transaction.
  
   If you have ideas, suggestions, etc. please follow up to this post
   until we find a more suitable place for such a discussion.
  
   Open Questions (my suggestions in brackets):
   1.) Medium for discussion (Wiki? SVN?)
   2.) Library requirement (1.5 concurrent package?)
   3.) Minimum JDK Requirement (always the latest, i.e. 1.6)
   4.) Scope (all restricted as possible)
   5.) What else?
  
   Cheers
  
   Oliver
  
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] Committing to collections-java5 branch

2007-03-11 Thread Oliver Zeigermann


Hi Stephen (C)!

Could you explain what your understanding of a 'reboot' is? As opposed
to the port to generics?

Anyway, from what I see in my daily work 1.5 really is widely
distributed and safe to rely on. Commons Transaction 2.0 will
certainly require it.

Oliver

2007/3/11, Stephen Colebourne [EMAIL PROTECTED]:

OK Stephens (and anyone else!),
I'm not in a position to just grant commit access (I wish I could, but
thats not the Apache way). However, I am willing to review and apply
patches to get generified collections off the ground.

We already have a generics branch which is intended to be a 'reboot' of
collections rather than a port to generics.

The first decision that needs to be made is whether you want to work on
a port or a 'reboot'. There is merit in both, and I'm willing to go with
the group decision. So start discussing!!!

Stephen
PS. As a general point, I get the sense that Java 5 is now really in the
ascendant, and we could do with generified versions of other commons
components sooner rather than later in order to stay relevant.


Stephen Smith wrote:
 Stephen C, if you're looking for volunteers you can count me in - although 3
 Stephens working on the same code might get a bit complicated. :)

 On Fri Mar  9  8:28 , Stephen Kestle  sent:

 Hi, I'd like to help work on the generics stuff for collections, as I've
 benefited in the past from it.  Stephen (C), it looks like you're quite
 busy and could use a hand, so let me know...

 Cheers

 Stephen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] Committing to collections-java5 branch

2007-03-11 Thread Oliver Zeigermann


Oh, ok. I do not have a say here, but this would be my preferred way.
I think the general redesign of the standard Java Collection makes it
necessary to rethink the commons collection idea from first
principles.

What is missing in Java 5 Collections? might be the guiding question.

Oliver

2007/3/11, Stephen Colebourne [EMAIL PROTECTED]:

Oliver Zeigermann wrote:
 Could you explain what your understanding of a 'reboot' is? As opposed
 to the port to generics?

A brand new implementation based on the same idea.
StarTrek TNG, Battlestar Galactica, ...
Stephen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULT] [VOTE] Release Commons Transaction 1.2

2007-03-11 Thread Oliver Zeigermann


Hi all!

The vote to release Commons Transaction 1.2 final has passed with the
following votes:

Oliver Zeigermann +1
Jörg Heinicke +1 (non-binding)
Daniel Florey +1
Tim O'Brien +1
Oliver Heger +1
Jörg Schaible +1

I will roll out the release ASAP.

Oliver

2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]:

Folks!

Every now and then I make a new approach to finally release commons
transaction 1.2. I have created a branch for the 1.2 version now

TRANSACTION_1_2_RELEASE_BRANCH

and a release tag

TRANSACTION_1_2_RELEASE

And have put up the rc4 to

http://people.apache.org/~ozeigermann/tx-1.2rc4/

for inspection. This includes the distributions and a preview of the
site updated for 1.2.

To release 1.2 final based on that release candidate here is my

+1

Cheers

Oliver



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Brainstorming for 2.0

2007-03-09 Thread Oliver Zeigermann


Packae naming:

As discussed here

http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL 
PROTECTED]

it might be a good idea to have a new package name for the 2.x version.

I'd be +1 for that

Oliver

2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]:

Folks!

As explaining in my previous post, I have created a new TRANSACTION2
branch to contain initial code, docs, etc. for a future 2.0 version of
Commons Transaction.

If you have ideas, suggestions, etc. please follow up to this post
until we find a more suitable place for such a discussion.

Open Questions (my suggestions in brackets):
1.) Medium for discussion (Wiki? SVN?)
2.) Library requirement (1.5 concurrent package?)
3.) Minimum JDK Requirement (always the latest, i.e. 1.6)
4.) Scope (all restricted as possible)
5.) What else?

Cheers

Oliver



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Brainstorming for 2.0

2007-03-08 Thread Oliver Zeigermann


2007/3/4, Joerg Heinicke [EMAIL PROTECTED]:

Oliver Zeigermann oliver.zeigermann at gmail.com writes:

 As explaining in my previous post, I have created a new TRANSACTION2
 branch to contain initial code, docs, etc. for a future 2.0 version of
 Commons Transaction.

 If you have ideas, suggestions, etc. please follow up to this post
 until we find a more suitable place for such a discussion.

 Open Questions (my suggestions in brackets):
 1.) Medium for discussion (Wiki? SVN?)

Why not this list? Do you expect so much discussion?


OK


 3.) Minimum JDK Requirement (always the latest, i.e. 1.6)

Hmm, why require more than necessary? Java 5 brings the concurrent package, but
Java 6? Higher requirements always limit the number of users.


OK


 4.) Scope (all restricted as possible)

Scope of what? Access scope of interfaces, classes, methods? Normally I tend to
limit it as less as possible to allow easy extending and sub classing. But if
changes to the API are always related with such circumstances ...


Scope of the implementation. Means only implement core, leave the rest
to optional modules and custom implementation.

My idea (and what I have learned from 1.x) is to only impement a core
that does the transactional part. The rest can in done through calling
implementation of interfaces
- How does a transaction map to temporary data
- Where is temporary data and final data stored (maybe use VFS?)
- Id generator
- what else?

There should be a default implementation for interfaces, but it should
be slim and rudimentary. This may result in having a transactional
file store out of the box.

Open Questions:
- Is Jakarta Commons the right place for such a project?
- Should we introduce threading in order to
 - Allow remote access / administration to a file store
 - Allow for deadlock detection in its own thread
- what else?

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Commons Transaction 1.2

2007-03-08 Thread Oliver Zeigermann


Hi Jörg!

Thanks for checking :)

Concerning the maven build and the geronimo jars you are right. I had
to change to repository to a local one to build it.

This is supposed to be changed as soon as the geronimo jars are
available over the standard repos.

Cheers

Oliver

2007/3/9, Jörg Schaible [EMAIL PROTECTED]:

Hi Oliver,

+1

build from source with Ant on Linux with Sun JDK 1.4, 1.5, and 1.6, with IBM
JDK 1.4, Blackdown JDK 1.4 and JRockit 1.4.

however, there were some problems with the build. Maven does not work, since
it does not find its deps:

= % ===
[EMAIL PROTECTED] ~/java/commons-transaction-1.2-src $ maven clean test
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

Attempting to download geronimo-j2ee-connector_1.5_spec-1.1.jar.
WARNING: Failed to download geronimo-j2ee-connector_1.5_spec-1.1.jar.
Attempting to download geronimo-jta_1.0.1B_spec-1.1.jar.
WARNING: Failed to download geronimo-jta_1.0.1B_spec-1.1.jar.
Attempting to download geronimo-servlet_2.4_spec-1.1.jar.
WARNING: Failed to download geronimo-servlet_2.4_spec-1.1.jar.
Attempting to download commons-codec-1.2.jar.
29K downloaded
Attempting to download commons-logging-1.1.jar.
51K downloaded
The build cannot continue because of the following unsatisfied dependencies:

geronimo-j2ee-connector_1.5_spec-1.1.jar
geronimo-jta_1.0.1B_spec-1.1.jar
geronimo-servlet_2.4_spec-1.1.jar

Total time: 10 seconds
Finished at: Fri Mar 09 04:33:03 CET 2007
= % ===

The IBM JDK 1.5.0.3 and JRockit 1.5.0.6 compiler tries to open the .pom file
as archive that it finds on the classpath and fail with an error:

= % ===
build:
[javac] Compiling 37 source files
to /home/joehni/java/commons-transaction-1.2-src/build/classes
[javac] error: error
reading 
/home/joehni/java/commons-transaction-1.2-src/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom;
Error opening zip
file 
/home/joehni/java/commons-transaction-1.2-src/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom
= % ===
build:
[javac] Compiling 37 source files
to /home/joehni/java/commons-transaction-1.2-src/build/classes
[javac] error: error
reading 
/home/joehni/java/commons-transaction-1.2-src/lib/geronimo-j2ee-connector_1.5_spec-1.1.pom;
Could not find End Of Central Directory
= % ===

You should use a pattern in the file set.

Nothing that prevents the vote to be cancelled though.

- Jörg



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Release Commons Transaction 1.2


Folks!

Every now and then I make a new approach to finally release commons
transaction 1.2. I have created a branch for the 1.2 version now

TRANSACTION_1_2_RELEASE_BRANCH

and a release tag

TRANSACTION_1_2_RELEASE

And have put up the rc4 to

http://people.apache.org/~ozeigermann/tx-1.2rc4/

for inspection. This includes the distributions and a preview of the
site updated for 1.2.

To release 1.2 final based on that release candidate here is my

+1

Cheers

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[transaction] Heads up: Two new branches


Folks!

I have create two new branches for Commons Transaction:
https://svn.apache.org/repos/asf/jakarta/commons/proper/transaction/branches/
- TRANSACTION_1_2_RELEASE_BRANCH: The release branch for the upcoming
1.2 final and all subsequent maintenance releases. E.g. 1.2.1 will be
spawned from this branch
- TRANSACTION2: Branch for initial 2.0 code. Features and policies
will have to be discusseed, but a lot of ideas simply are not
compatible with what we have done for 1.x. More to come on this
specific topic.

1.x development will continue on the TRUNK, e.g. 1.3 will be spawned
from it. All new features go into the TRUNK

Cheers

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[transaction] Brainstorming for 2.0


Folks!

As explaining in my previous post, I have created a new TRANSACTION2
branch to contain initial code, docs, etc. for a future 2.0 version of
Commons Transaction.

If you have ideas, suggestions, etc. please follow up to this post
until we find a more suitable place for such a discussion.

Open Questions (my suggestions in brackets):
1.) Medium for discussion (Wiki? SVN?)
2.) Library requirement (1.5 concurrent package?)
3.) Minimum JDK Requirement (always the latest, i.e. 1.6)
4.) Scope (all restricted as possible)
5.) What else?

Cheers

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Commons Transaction 1.2


Hi Niall!

Thanks for checking that.

The jars are the new ones from David, yes. But AFAIK you can not get
them over the standard Maven repositories. It least I could not.
That's why they are in the distro.

That can be changed with the next release (1.3 or 1.2.1) when the jars
can be retrieved over the standard Maven repository.

So, this is no objection to me, unless you vote with a -1 ;)

Cheers

Oliver

2007/3/4, Niall Pemberton [EMAIL PROTECTED]:

My understanding was that David Blevins had kindly created JDK 1.3
compatible versions of the geronimo dependencies that transaction
needs - see http://tinyurl.com/yw2j4e

From what I can see from the geronimo vote threads they seemed to have
passed - but the final release steps not yet completed. I'm sure a
ping to David would resolve this.

David resolving the JDK 1.3 issue with the Geronimo jars removes the
necessity of having jars in the subversion repo for transaction -
which was an objection from a number of people over the last
transaction 1.2 RC. From what I can see looks like the same objections
still stand for this RC?

Niall

On 3/4/07, Oliver Zeigermann [EMAIL PROTECTED] wrote:
 Folks!

 Every now and then I make a new approach to finally release commons
 transaction 1.2. I have created a branch for the 1.2 version now

 TRANSACTION_1_2_RELEASE_BRANCH

 and a release tag

 TRANSACTION_1_2_RELEASE

 And have put up the rc4 to

 http://people.apache.org/~ozeigermann/tx-1.2rc4/

 for inspection. This includes the distributions and a preview of the
 site updated for 1.2.

 To release 1.2 final based on that release candidate here is my

 +1

 Cheers

 Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Commons Transaction 1.2


2007/3/4, Niall Pemberton [EMAIL PROTECTED]:

On 3/4/07, Oliver Zeigermann [EMAIL PROTECTED] wrote:
 Hi Niall!

 Thanks for checking that.

 The jars are the new ones from David, yes. But AFAIK you can not get
 them over the standard Maven repositories. It least I could not.
 That's why they are in the distro.

 That can be changed with the next release (1.3 or 1.2.1) when the jars
 can be retrieved over the standard Maven repository.

 So, this is no objection to me, unless you vote with a -1 ;)

Its not something that would cause me to vote against the release -
but it does seem a shame, given the number of comments from others in
previous threads, to not at least ping David first and try to keep
everyone happy.


1.2 is not going to be the final version in history. AFAIK the policy
is release early, release often. The main question to me is: Is this
1.2 release going to be better than the existing final 1.1? Or put the
other way round: Is it a good idea to replace 1.1 as the official
version with 1.2? And my answer: It is by all means!

That's why - INHO - removing the jars can wait until 1.3 or 1.2.1.

Cheers

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Towards a Commons Transaction 1.2 release

2007-01-21 Thread Oliver Zeigermann


Hi!

Sorry for being mostly inactive, lately.

This is not supposed to change in the next time as I am really busy, though :(

However, inspite of my limited time, I still tried to bring the 1.2
release out TWICE and TWICE there - IMHO - was too much talk without
leading us anywhere, effectively blocking the release without - again
IMHO - substantial cause.

Because of this I would be more than happy if *someone else* could do
something more *productive* and finally finish the release.

Finally, many thanks to Jörg for actually doing productive work and
keeping the project alive

AND

my +1 for the release

Cheers

Oliver

2007/1/20, Joerg Heinicke [EMAIL PROTECTED]:

Hi everybody,

I wonder if there can finally be a Commons Transaction 1.2 release. Half
a year ago we already had a RC 3 [1] which did not get released at that
time not due to a specific reason. There were discussions about getting
the jars at build time [2]. This issue came up again [3] when talking
about a release recently [4].

If somebody wants to do this step I'm fine with it, but IMHO it should
not block the release. When doing the step one should also have in mind
the necessity of 1.3 compiled Geronimo jars. David Blevins offered to
help here [5, 6], but I don't know about any progress (cc-ing him).

The code in SVN as is must be built with a JDK 1.4+ to include the JCA
stuff. The target JDK 1.3 is addressed automatically by the build system.

All other issues like interface compatibility [7] or license headers [8]
have been addressed [9] or are obsolete with a new RC.

So what is left?

I gathered all those links and information as I will be off for the next
5 weeks (New Zealand :) ) and somebody else can jump on the train. I
don't know how much time Oliver has. He is rather quiet lately.

I'd like to see a Commons Transaction 1.2 release after coming back.
Here is my +1 in advance :)

Regards
Jörg

[1] http://marc.theaimsgroup.com/?t=11541897323r=1w=4
[2] http://marc.theaimsgroup.com/?t=11542281691r=1w=4
[3] http://marc.theaimsgroup.com/?t=11681461061r=1w=4
[4] http://marc.theaimsgroup.com/?t=11672486174r=1w=4
[5]
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116838095403943w=4
[6]
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116845728730516w=4
[7] http://marc.theaimsgroup.com/?t=11682925535r=1w=4
[8]
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116783675420686w=4
[9]
http://marc.theaimsgroup.com/?l=jakarta-commons-devm=116855776015241w=4




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] svn commit: r494203 - in /jakarta/commons/proper/transaction/trunk: RELEASE-NOTES.txt src/java/org/apache/commons/transaction/file/ResourceManager.java

2007-01-13 Thread Oliver Zeigermann


Folks!

Thanks for caring that much and sorry for me being quiet until now as
I am the guilty person.

The design we are talking about actually is quite weird as it is a
stub of a former implementation. There is this interface and there is
*exactly* one implementation for that interface and IMHO there will be
no - reasonable - further implementation at any time. Thus it is
alright to extend the interface.

Even if you do not agree we should at least add the additional methods
to the implementation, leaving the interface untouched, breaking
nothing!

OK?

Cheers and have a nice weekend

Oliver

2007/1/11, Simon Kitching [EMAIL PROTECTED]:

On Wed, 2007-01-10 at 14:12 -0500, Rahul Akolkar wrote:
 On 1/10/07, Joerg Heinicke [EMAIL PROTECTED] wrote:
  Rahul Akolkar rahul.akolkar at gmail.com writes:
 
Generally speaking, an interface-compatible change will at most change 
the
private interface of a component, or simply add classes, methods and
attributes whose use is optional to both internal and external interface
clients.
  
   And this is not.
 
  In which way is it different from simply add [..] methods [..] whose use is
  optional to both internal and external interface clients. ??
 
  Even simply replacing the former jar with the next version should work as 
the
  client does not know about the new methods. Only recompilation of
  implementations need adaptions before but that's not what I consider a 
use or
  a client.
 
 snip/

 I suspect that bit is talking about Java classes (rather than
 interfaces), though I haven't tried to hunt it down in the guide. I
 flagged what I thought would lead to a versioning discussion at 1.2
 voting time.

There is a section in the java specification that defines precisely what
binary compatibility involves, and adding a method to an interface
definitely breaks it.

This is an *object oriented* library we are talking about here, so use
includes implementing any public interfaces, subclassing any non-final
classes and overriding any public or protected methods. Unless
explicitly documented, we cannot assume that users of an open-source
library restrict themselves to just calling the existing classes.

If the interfaces had been explicitly documented as being not intended
for user implementation then this might be ok. Or if they had been
placed in a special package, as Eclipse does, to explicitly separate
internal from external apis. However if neither of these have been done,
then I would personally expect these APIs to be binary-compatible, *at
least* without a major version number update.

In the branch for digester 2.x, I explicitly indicated the binary
stability expectations for the Action interface:
http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/Action.java
Note that this is still experimental work, and I haven't received
feedback from the commons community on whether this sort of comment
would be considered adequate to allow an interface change in a minor
release, but IMO without an indication of this sort an API really
shouldn't change (without a major release at least).

Ideally, existing public interfaces should not be changed *at all*, eg
by introducing a new interface rather than changing the existing one. In
cases where an application uses two different libraries that both depend
on a commons lib, the existence of different versions of the commons lib
with the same package names but different APIs can cause major
headaches.

As Rahul says this situation may well draw -1 votes at release time. We
all want commons projects to have a good reputation for API stability.
There have been mistakes made in the past, causing a lot of negative
user feedback. Yes, it can be a hassle for development. However the
reason that commons is a good place to host libraries is because commons
is trusted, and that's because the software development processes here
are reasonably strict. Writing libraries is hard - and quite different
from writing full applications (eg tomcat, ant) or frameworks.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Release Commons Transaction 1.2

2006-12-27 Thread Oliver Zeigermann


We have worked our way through three release candidates now and the
latest has been out there for quite some time without substantial
shortcomings reported:

http://people.apache.org/~ozeigermann/tx-1.2rc3/

To release 1.2 final based on that release candidate here is my

+1

Cheers

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-13) JTA Compliant

2006-12-18 Thread Oliver Zeigermann (JIRA)

[ 
http://issues.apache.org/jira/browse/TRANSACTION-13?page=comments#action_12459336
 ] 

Oliver Zeigermann commented on TRANSACTION-13:
--

There are no such plans, but commons tx could serve as a basis for such an 
implementation

 JTA Compliant
 -

 Key: TRANSACTION-13
 URL: http://issues.apache.org/jira/browse/TRANSACTION-13
 Project: Commons Transaction
  Issue Type: New Feature
Reporter: Cyrille

 Is there a plan to make Commons-Transaction compliant with JTA (Java 
 Transaction API) ?
 It would be great to get it.
 For exemple, in case of a web file upload, we could make one transaction for 
 tose 2 operations :
 1) writing metadata in database (title,description...),
 2) writing the file on the filesystem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Regarding apache commons file transactions ~script

2006-09-15 Thread Oliver Zeigermann


Hi Praven!

You have to delete the file using the FileResourceManager.

Oliver

2006/9/15, Praveen Kumar [EMAIL PROTECTED]:

*** CAUTION ***

The sender of this email has requested that its content is not checked
for potentially mailicious scripts.  Therefore this email has been virus
checked, but advanced content security checks have not been carried
out. Please take extra care when handling this email and any associated
attachments.  The original message now follows.

 Hi,

 I need your help to solve my technical problem. Many thanks in
 advance.

 I am using apache commons file transactions for my application. As per
 my requirement i have to rollback the file deletion if any abnormal
 condition occurs in a transaction. For that i wrote below code.


 Logger logger =
 Logger.getLogger(test.class.getName());
 LoggerFacade sLogger = new Jdk14Logger(logger);

 FileResourceManager frm = new
 FileResourceManager(store, work, false, sLogger, true);
 Object txId = getTranscationId(new Date().getTime());
 try {
   frm.start();
   frm.prepareTransaction(txId);
   frm.startTransaction(txId);
   frm.lockResource(url, txId);
   FileHelper fh = new
 FileHelper();
   fh.deleteFile(url);
   frm.commitTransaction(txId);
 } catch (ResourceManagerException  e) {
   try {
 frm.rollbackTransaction(txId);
   }


 When i test the above code by placing throw new
 ResourceManagerException() after  fh.deleteFile(url) statement, by
 commenting the frm.commitTransaction(txId) statement, the control is
 coming to catch block. But, file deletion can't rollback. I mean after
 transaction rollback the file doesn't place in actual directory.

 One more doubt using apache commons, can i delete a file which is
 exist in remote server?

 Kindly, help me. Awaiting for your reply.

 Thanks  Regards,
 Praveen

This communication is confidential and intended solely for the addressee(s). 
Any unauthorized review, use, disclosure or distribution is prohibited. If you 
believe this message has been sent to you in error, please notify the sender by 
replying to this transmission and delete the message without disclosing it. 
Thank you.

E-mail including attachments is susceptible to data corruption, interruption, 
unauthorized amendment, tampering and viruses, and we only send and receive 
e-mails on the basis that we are not liable for any such corruption, 
interception, amendment, tampering or viruses or any consequences thereof.


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-12) Use NIO for file copying/moving

2006-09-02 Thread Oliver Zeigermann (JIRA)

[ 
http://issues.apache.org/jira/browse/TRANSACTION-12?page=comments#action_12432306
 ] 

Oliver Zeigermann commented on TRANSACTION-12:
--

Renaming (rename-first as you call it) is already done by the current 
implementation. 

The current fall back strategy is used as commons transaction only requires 
Java 1.3 which does not support NIO. It might be an option to have different 
implementations for pre 1.4 and post 1.4 JDKs though. Could you think of 
something like that?

 Use NIO for file copying/moving
 ---

 Key: TRANSACTION-12
 URL: http://issues.apache.org/jira/browse/TRANSACTION-12
 Project: Commons Transaction
  Issue Type: Wish
Affects Versions: 1.2
Reporter: Holger Hoffstätte
 Attachments: moveByRenameAndNIO.txt


 The Mule project (http://mule.codehaus.org/) is considering adoption of 
 commons-transaction for (among other things) file transactions. Unfortunately 
 inspection of the code reveals that FileHelper copies files in the slowest 
 possible way (traditional Java I/O via Input/OutputStreams). Since some of 
 our users move lots and/or large files (hundreds of megabytes to gigabytes) 
 we implemented file moving by rename (atomic and obviously very fast when 
 source and target are on the same filesystem) and NIO as backup strategy (a 
 lot less CPU usage).
 Attached is a code snippet that outlines the procedure; it would be cool if 
 c-tx could adopt a similar strategy for moving via rename-first and copy via 
 NIO. I do not know if and how this might conflict with c-tx's transactional 
 behaviour and recovery but then again it is just a suggestion. :-)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [convert] Project restart ?

2006-08-01 Thread Oliver Zeigermann


2006/7/31, Kris Nuttycombe [EMAIL PROTECTED]:

I'd be happy to donate a little time, if someone could give a report on
what the current state of the project is and what needs to be done. Data
conversion is a significant issue where I work.


I guess convert is much more about converting one Java structure to
another. I need data conversion tools as well, but I doubt commons is
the right place for that.

WDYT?

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Commons Transaction 1.2 rc3 ready for inspection

2006-08-01 Thread Oliver Zeigermann


2006/7/31, Rahul Akolkar [EMAIL PROTECTED]:

On 7/30/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:
 2006/7/30, Rahul Akolkar [EMAIL PROTECTED]:
snip/
 
  IMO:
 
   * Its straightforward to provide an ant target to download the deps.

 Oh. I am ignorant. Did not know that. How does this work? That might
 be an option.

snap/

The [scxml] (m1 generated) build.xml is an example, or any other m1
generated component ant build files too (build grabs deps from
ibiblio).


Found it. Indeed looks simple. Thanks for that :)

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Commons Transaction 1.2 rc3 ready for inspection

2006-07-31 Thread Oliver Zeigermann


2006/7/31, Joerg Heinicke [EMAIL PROTECTED]:

On 7/29/06, Oliver Zeigermann oliver.zeigermann at gmail.com wrote:

 Finally there is the third release candidate at
 http://people.apache.org/~ozeigermann/tx-1.2rc3/

From a functionality POV it works for me. Regarding JDK 1.3 ([1]): How did you
solve the problem with the J2EE/Geronimo jars? Did you recompile them?


I compiled against Suns J2EE jar which was compiled using JDK 1.3. I
still include Geronimo jars as Suns jars are not license compatible.

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Commons Transaction 1.2 rc3 ready for inspection

2006-07-30 Thread Oliver Zeigermann


2006/7/30, Rahul Akolkar [EMAIL PROTECTED]:

 * Why are the dependencies (the lib folder) included in both distros?
I'd prefer that they aren't, is there any particular reason why
[transaction] does that?


The main build process uses ant which requires these libraries.


 * The source distro contains the jar -- which I wouldn't expect to be there.


I thought that was the regular way. I.e. commons IO has the jar in the
source distribution as well.


And as a minor nit, there are 7 odd Javadoc warnings.


I will have a look at it.

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Commons Transaction 1.2 rc3 ready for inspection

2006-07-30 Thread Oliver Zeigermann


2006/7/30, Rahul Akolkar [EMAIL PROTECTED]:

On 7/30/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:
 2006/7/30, Rahul Akolkar [EMAIL PROTECTED]:
   * Why are the dependencies (the lib folder) included in both distros?
  I'd prefer that they aren't, is there any particular reason why
  [transaction] does that?

 The main build process uses ant which requires these libraries.

snip/

I'm not in favor of distributing deps along with Commons libraries'
distributions.

IMO:

 * Its straightforward to provide an ant target to download the deps.


Oh. I am ignorant. Did not know that. How does this work? That might
be an option.


 * Distribution of (potentially) 3rd party binaries (as an example,
JUnit, in this case) means we have to understand their licenses (by
refering to the ASF legal docs), determine reciprocity requirements as
needed etc. No bang for the buck here.


JUnit is save to use. All others are from Apache. Anyway, maybe they
could be kept optional.

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [collections] Maps supporting concurrent modification of their iterators?

2006-07-30 Thread Oliver Zeigermann


2006/7/30, Stephen Colebourne [EMAIL PROTECTED]:

Robert Ribnitz wrote:
 how much work would be involved in extending one of the Maps provided in
 the collections framework to support concurrent modification of the
 structures their mapIterators iterate over?

 would this be an envisageable feature? - I am thinking of Maps behaving
 much like the CursorableLinkedList.

I guess that this would be possible. I've never had a need for
concurrent access personally, as I just refactor the code to not need it.


Interesting. How does that work?

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

transaction] Commons Transaction 1.2 rc3 ready for inspection

2006-07-29 Thread Oliver Zeigermann


Hi folks!

Finally there is the third release candidate at

http://people.apache.org/~ozeigermann/tx-1.2rc3/

Compiled using a 1.3 JDK, and with the proper md5 format.

I hope this is ok now. Is it?

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Preparing a release

2006-07-25 Thread Oliver Zeigermann


Hey, Henri!

Thanks for the detailed feedback. Most of it should be fixed now. One
more question: Where is the jar supposed to be? In the binary dist? It
alreay is there! Or in the release directory? When to place the POM?

Oliver

2006/7/25, Henri Yandell [EMAIL PROTECTED]:

On 7/24/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:
 Hi folks!

 I have already uploaded the files for a 1.2 release candidate to

 http://people.apache.org/~ozeigermann/tx-1.2rc1/

Have you read the Releasing Components webpages?

Few things to change:

.MD5 to .md5
.tgz to .tar.gz
zips and tar.gz's should unzip to a directory with the same name as
the archive (ie: it shouldn't make a mess when unpacked)
include a jar for the Maven repository (and a .pom)
gpg sign all files

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[transaction] Commons Transaction 1.2 rc2 ready for inspection

2006-07-25 Thread Oliver Zeigermann


Hi folks!

After I have (hopefully) fixed Henris objections I have put up a
second release candidate here:

http://people.apache.org/~ozeigermann/tx-1.2rc2/

Tests all succeed and to me it looks fine. Is that release candidate
ready for prime time?

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[transaction] problem with JDK 1.3

2006-07-25 Thread Oliver Zeigermann


Hi folks!

I really have problems compiling Commons Transaction with a 1.3 JDK.
Every tool/jar seems to be compiled with at least JDK 1.4! I either
need a pointer ot a BSD/ASF 1.3 compiled j2ee spec and servlet api jar
or vote to require an 1.4 JDK for commons transaction.

Opinions? Links?

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[transaction] Preparing a release

2006-07-24 Thread Oliver Zeigermann


Hi folks!

I have already uploaded the files for a 1.2 release candidate to

http://people.apache.org/~ozeigermann/tx-1.2rc1/

Not quite sure where to go from here.

Do we need a vote for the release candidate?

Where to put the files for the release candidate for public inspection?

Thanks in advance for any hints and cheers

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] splitting ResourceManager interface

2006-07-17 Thread Oliver Zeigermann


2006/7/15, Joerg Heinicke [EMAIL PROTECTED]:

(OT: Sometimes ago I mentioned that this XAResource implementation might be
donated to Commons Transaction. I got no go from my employer at that time. We
were taken over by another company and our management did not want to decide
about those things. Maybe I should put it back on the table ...)


Nice idea. I think that would be a valuable contribution.


 Anyway, TransactionManager wouldn't be such a good name for a new
 class as it has a predefinied meaning in the J2EE world I guess.

Ok, naming clashes might better be avoided. But from the meaning I chose the
name after comparing with the JTA TransactionManager interface as the
ResourceManager's methods related to transaction handling and the JTA
TransactionManager methods are quite similar. So I don't think there is a
different meaning. And how many ResourceManagers exist in the world? ;)


Hehe, right...


About Java 5: I have never used it yet. Don't know what it can really buy us
though I read much about its nice features.


I would buy us the new concurrent package which has taken over Doug
Leas work. Very nice.

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2006-07-17 Thread Oliver Zeigermann (JIRA)

[ 
http://issues.apache.org/jira/browse/TRANSACTION-9?page=comments#action_12421661
 ] 

Oliver Zeigermann commented on TRANSACTION-9:
-

That looks really interesting. Not quite sure what to do with it, though. I 
would like to check it into something like a proposal section or a scratchboard 
for public inspection. 

What do you people think?

 [transaction] Add full file management capabilities to the FileResourceManager
 --

 Key: TRANSACTION-9
 URL: http://issues.apache.org/jira/browse/TRANSACTION-9
 Project: Commons Transaction
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: All
Reporter: Peter Fassev
Priority: Minor
 Attachments: filemanager.zip


 Hi,
 As stated in the doc the FileResourceManager is:
 A resource manager for streamable objects stored in a file system
 I agree, that this is a resource manager, but it could be easily extended, to 
 support a full file management system. It will be very helpful to have 
 additional methods like renameResource(), getResourceSize(), 
 getResourceTime(), 
 setResourceTime() etc. This are common file operations, which should be 
 managed 
 by the FileResourceManager.
 Further it will be very helpful to have (real) support for resource 
 collections 
 (folders). It will be necessary to distinguish between single resources 
 (files) 
 and collections (folders). 
 Together, this features will enable a transactional access to any file based 
 resources - for instance a document repository.
 Are there plans for such extensions and if not, will they actually fit in the 
 goals of the transaction library?
 If not, please open the underlying structure, like the inner class 
 TransactionContext, in order to add extensions the file management. For 
 instance, it will be good to have a separate factory method, which creates 
 the 
 context.
 If you are interested in this proposal, I am ready to contribute to this 
 project. I consider myself as an experienced java developer and I will be 
 glad 
 to help you. 
 Best regards
 Peter Fassev

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-10) [transaction] Migrating to commons-logging

2006-07-15 Thread Oliver Zeigermann (JIRA)

[ 
http://issues.apache.org/jira/browse/TRANSACTION-10?page=comments#action_12421348
 ] 

Oliver Zeigermann commented on TRANSACTION-10:
--

Sure, add the Commons Logging LoggerFacade implementation!

Oliver

 [transaction] Migrating to commons-logging
 --

 Key: TRANSACTION-10
 URL: http://issues.apache.org/jira/browse/TRANSACTION-10
 Project: Commons Transaction
  Issue Type: Improvement
Affects Versions: 1.1
 Environment: Operating System: All
 Platform: Other
Reporter: Esteban Sancho
Priority: Minor
 Attachments: CommonsLoggerFacade.java


 Hi folks,
 Might I suggest to migrate from LoggerFacade to commons-logging?
 The reasons would be:
 1) It's a commons package
 2) Easier integration on almost every project
 3) The API user shouldn't have to take care about the logging strategy. I 
 think
 the API would be much easier to use.
 I'm asking this because it was pretty hard for me to debug a problem using 
 this
 package with Jotm. At last, it was a bug in Jotm but I needed to almost 
 rewrite
 the logging strategy to find it. I made my own branch (backward incompatible) 
 to
 debug the problem and then restablished the original package.
 Please let me know your thoughts and I'd be glad to help in the task.
 Thanks,
 Esteban

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Release plan?


2006/7/14, Joerg Heinicke [EMAIL PROTECTED]:

Oliver Zeigermann oliver.zeigermann at gmail.com writes:

 Excatly! That's just what I was proposing in my last email!


 2006/7/13, Henri Yandell flamefew at gmail.com:
  Is the aim to have a 1.2 release of transaction at some point?


Yes, I would like to see a 1.2 release as well. There are enough fixes and
enhancements that qualify for a new release.

What's the actual release process (code freeze, etc.)?


Feature freeze for 1.2 is exactly now ;)

More info can be found here:

http://jakarta.apache.org/commons/releases/release.html
http://jakarta.apache.org/commons/releases/prepare.html

I'd go for a release candidate right now, skipping betas. Opinions?


RELEASE-NOTES.txt talks about 1.1.1 while we now will probably name it 1.2 btw.


Oh, right. Will fix this.

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Release plan?


2006/7/14, Henri Yandell [EMAIL PROTECTED]:

On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:
 Excatly! That's just what I was proposing in my last email!

 Would you want to assist?

Definitely happy to assist with getting the release out there etc. No
real itch on transactions themselves, but I want to do what I can to
speed up our release cycles.


Cool :)


I'll go through jira tonight and do the same thing I'll do for Pool;
add version information for all new/old issues.


Great!

Thanks a lot!

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Release plan?


2006/7/14, Niall Pemberton [EMAIL PROTECTED]:

On 7/13/06, Henri Yandell [EMAIL PROTECTED] wrote:
 On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:
  Excatly! That's just what I was proposing in my last email!
 
  Would you want to assist?

 Definitely happy to assist with getting the release out there etc. No
 real itch on transactions themselves, but I want to do what I can to
 speed up our release cycles.

I don't have an itch/need for transaction either but am also happy to
help with build/site issues that normally get raised with release
candidates, if you want.


Nice. I will certainly came back to you with questions ;)


Is maven the primary build mechanism (i.e. the one you use for
release)?  Also what is the minimum JDK version for transaction?


I used ant for the previous releases (target package). Minimum jdk is 1.2

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2006-07-14 Thread Oliver Zeigermann (JIRA)

[ 
http://issues.apache.org/jira/browse/TRANSACTION-9?page=comments#action_12421217
 ] 

Oliver Zeigermann commented on TRANSACTION-9:
-

That certainly is post 1.2

 [transaction] Add full file management capabilities to the FileResourceManager
 --

 Key: TRANSACTION-9
 URL: http://issues.apache.org/jira/browse/TRANSACTION-9
 Project: Commons Transaction
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: All
Reporter: Peter Fassev
Priority: Minor

 Hi,
 As stated in the doc the FileResourceManager is:
 A resource manager for streamable objects stored in a file system
 I agree, that this is a resource manager, but it could be easily extended, to 
 support a full file management system. It will be very helpful to have 
 additional methods like renameResource(), getResourceSize(), 
 getResourceTime(), 
 setResourceTime() etc. This are common file operations, which should be 
 managed 
 by the FileResourceManager.
 Further it will be very helpful to have (real) support for resource 
 collections 
 (folders). It will be necessary to distinguish between single resources 
 (files) 
 and collections (folders). 
 Together, this features will enable a transactional access to any file based 
 resources - for instance a document repository.
 Are there plans for such extensions and if not, will they actually fit in the 
 goals of the transaction library?
 If not, please open the underlying structure, like the inner class 
 TransactionContext, in order to add extensions the file management. For 
 instance, it will be good to have a separate factory method, which creates 
 the 
 context.
 If you are interested in this proposal, I am ready to contribute to this 
 project. I consider myself as an experienced java developer and I will be 
 glad 
 to help you. 
 Best regards
 Peter Fassev

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRANSACTION-10) [transaction] Migrating to commons-logging

2006-07-14 Thread Oliver Zeigermann (JIRA)

 [ http://issues.apache.org/jira/browse/TRANSACTION-10?page=all ]

Oliver Zeigermann resolved TRANSACTION-10.
--

Resolution: Won't Fix

 [transaction] Migrating to commons-logging
 --

 Key: TRANSACTION-10
 URL: http://issues.apache.org/jira/browse/TRANSACTION-10
 Project: Commons Transaction
  Issue Type: Improvement
Affects Versions: 1.1
 Environment: Operating System: All
 Platform: Other
Reporter: Esteban Sancho
Priority: Minor
 Attachments: CommonsLoggerFacade.java


 Hi folks,
 Might I suggest to migrate from LoggerFacade to commons-logging?
 The reasons would be:
 1) It's a commons package
 2) Easier integration on almost every project
 3) The API user shouldn't have to take care about the logging strategy. I 
 think
 the API would be much easier to use.
 I'm asking this because it was pretty hard for me to debug a problem using 
 this
 package with Jotm. At last, it was a bug in Jotm but I needed to almost 
 rewrite
 the logging strategy to find it. I made my own branch (backward incompatible) 
 to
 debug the problem and then restablished the original package.
 Please let me know your thoughts and I'd be glad to help in the task.
 Thanks,
 Esteban

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

2006-07-14 Thread Oliver Zeigermann (JIRA)

[ 
http://issues.apache.org/jira/browse/TRANSACTION-9?page=comments#action_12421219
 ] 

Oliver Zeigermann commented on TRANSACTION-9:
-

Peter, that's pretty cool! Jörg seems to plan some more radical 
changes/extensions pointing to the same direction. We currently discuss this on 
the commons dev list. Please join us. Anyway, if you would want to donate your 
work to the transactions package, please add some code / patch to this issue.

Thanks 

Oliver

 [transaction] Add full file management capabilities to the FileResourceManager
 --

 Key: TRANSACTION-9
 URL: http://issues.apache.org/jira/browse/TRANSACTION-9
 Project: Commons Transaction
  Issue Type: Improvement
 Environment: Operating System: All
 Platform: All
Reporter: Peter Fassev
Priority: Minor

 Hi,
 As stated in the doc the FileResourceManager is:
 A resource manager for streamable objects stored in a file system
 I agree, that this is a resource manager, but it could be easily extended, to 
 support a full file management system. It will be very helpful to have 
 additional methods like renameResource(), getResourceSize(), 
 getResourceTime(), 
 setResourceTime() etc. This are common file operations, which should be 
 managed 
 by the FileResourceManager.
 Further it will be very helpful to have (real) support for resource 
 collections 
 (folders). It will be necessary to distinguish between single resources 
 (files) 
 and collections (folders). 
 Together, this features will enable a transactional access to any file based 
 resources - for instance a document repository.
 Are there plans for such extensions and if not, will they actually fit in the 
 goals of the transaction library?
 If not, please open the underlying structure, like the inner class 
 TransactionContext, in order to add extensions the file management. For 
 instance, it will be good to have a separate factory method, which creates 
 the 
 context.
 If you are interested in this proposal, I am ready to contribute to this 
 project. I consider myself as an experienced java developer and I will be 
 glad 
 to help you. 
 Best regards
 Peter Fassev

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] splitting ResourceManager interface


Hi, Jörg!

That certainly is post 1.2, right? Maybe even some work for a 2.0
version? More details inline.

2006/7/14, Joerg Heinicke [EMAIL PROTECTED]:

Actually I would like to address some different requirements with my
FileResourceManager, which I can no longer fulfill by just extending the current
one. Reimplementing the current ResourceManager interface would be absolute
overkill as the transactional stuff is exactly the same. It's only the resource
handling I need in a different way.

My use case: We have some data input and output dirs for different let's call
them communication partners and a common repository dir:

ROOT -- cp1 -- upload
 |  \- download
 |- cp2 -- upload
 |  \- download
 |
 \- repo

Up to now the data dirs and the repo dir had a common root to which I set the
store dir. But now data dirs and repo dir can be completely different. I could
set the store dir to / but I don't think that's really appropriate.
Furthermore the FileResourceManager does a recursive delete of directories so
that the data dir structure gets lost atm. With the current behaviour I would
need one FileResourceManager for every sub dir. This would be acceptable if they
had not such a huge overhead of lifecycle but would only be wrappers around file
system access. All instances would refer to one TransactionManager then. Another
possibility would be to allow the FileResourceManager to handle multiple store
dirs but I'd prefer the first approach.


Hmmm. Why do you need FileResourceManagers in the fist place? Just to
synchronize file access? Not quite sure here...

Anyway, TransactionManager wouldn't be such a good name for a new
class as it has a predefinied meaning in the J2EE world I guess.


 Anyway, if you want to introduce something new, got ahead, but be
 aware of backward compatibility issues.

The question is in which extend. Even simply stripping the transactional concern
from ResourceManager interface into its own and letting the FileResourceManager
implement both interfaces, can lead to incompatibilities if the methods for
transactional concern are called on the ResourceManager interface and not on the
FileResourceManager instance.


One way would be to leave the ResourceManager interface untouched and
introduce your two new interfaces. FileResourceManager would implement
all three interfaces.

Another idea would be to make it all better in 2.0 and do not care too
much for backward compatibility. One idea might be to even use Java 5
locking. Maybe this is stuff for another thread, though...

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Release plan?


2006/7/14, Niall Pemberton [EMAIL PROTECTED]:

On 7/14/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:
 2006/7/14, Niall Pemberton [EMAIL PROTECTED]:
  On 7/13/06, Henri Yandell [EMAIL PROTECTED] wrote:
   On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:
Excatly! That's just what I was proposing in my last email!
   
Would you want to assist?
  
   Definitely happy to assist with getting the release out there etc. No
   real itch on transactions themselves, but I want to do what I can to
   speed up our release cycles.
 
  I don't have an itch/need for transaction either but am also happy to
  help with build/site issues that normally get raised with release
  candidates, if you want.

 Nice. I will certainly came back to you with questions ;)

  Is maven the primary build mechanism (i.e. the one you use for
  release)?  Also what is the minimum JDK version for transaction?

 I used ant for the previous releases (target package). Minimum jdk is 1.2

OK, I updated the maven build earlier which even if you still use ant,
is good to have - I set maven.compile.target and maven
compile.source in project.properties to JDK 1.3, so you may want to
correct those (or I can)


Anything you can do for maven, please do! My tool is ant and I am
always lost with maven!

Thanks a lot in advance

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] splitting ResourceManager interface


Hi, Jörg!

My first implementation of FileResourceManager really implemented two
interfaces that were close to what you propose. The idea was to have
impementations other than to the file system. The ResourceManager
interface rather is some sort of relict from older times. No need to
worry much about it except for backward compatibility.

Why change things in the first place? Just because the
FileResourceManager is huge? That is not a bad thing all by itself.
Some classed simply get big. Compare it to the String class. It is
twice as big.

Anyway, if you want to introduce something new, got ahead, but be
aware of backward compatibility issues.

Oliver

P.S.: I think it might be the time for a 1.2 release. What do you think?

2006/7/13, Joerg Heinicke [EMAIL PROTECTED]:

Hello,

the more I work with the FileResourceManager the more I'm convinced that the
ResourceManager interface should be splitted into two interfaces: one for
handling the locking and transactional stuff (proposal: TransactionManager) and
one for actually handling the resources (as is: ResourceManager).

One the one hand the only implementation, the FileResourceManager, simply does
too much, i.e. too many concerns are handled in it. On the other hand I extend
my local version of the FileResourceManager with more and more methods to
emulate a file system access (methods from java.io.File actually). In theory I
would need to add these methods to ResourceManager interface to be able to work
with interfaces, but it would get bigger and bigger.

Instead I wonder if a generic ResourceManager interface (in my new sense as
described above) is appropriate at all. Probably it would be more appropriate to
rename it to FileResourceManager or introduce FileResourceManager interface
extending ResourceManager. The splitting of the current ResourceManager
interface would allow to reuse the transaction/locking capability with different
ResourceManagers (in my new sense).

The splitting should be quite easy IMHO. The concerns are quite good separated
in the FileResourceManager.

WDYT?

Regards,
Jörg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to I set JIRA issues to resolved?


Issues have moved from bugzilla and now I am rather helpless how to
set them to fixed.

Any ideas? Do I need additional rights?

Thanks in advance and cheers

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to I set JIRA issues to resolved?


2006/7/13, Thomas Dudziak [EMAIL PROTECTED]:

On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:

 Issues have moved from bugzilla and now I am rather helpless how to
 set them to fixed.

 Any ideas? Do I need additional rights?

There should be an Available Workflow Actions section on the left
side that contains things like Resolve issue, Close issue.
If you don't see that, then yes, you need additional rights.


How do I get those additional rights?

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to I set JIRA issues to resolved?


2006/7/13, Henri Yandell [EMAIL PROTECTED]:

On 7/13/06, Thomas Dudziak [EMAIL PROTECTED] wrote:
 On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:

  How do I get those additional rights?

 Usually the project owner/admin gives them. Though, for the commons
 projects there appears to be a specific user Jakarta Commons
 Developers for administering the projects. You should probably ask
 Henri about that.

Nah, that user is a side-effect of a user pulled over from Bugzilla.
We've kept it at the moment for project leads. Some of them anyway.

For additional rights you just need to ask. The rules I abide by are
that if you're a jakarta committer, I add you to the jakarta-developer
group and if you're a jakarta PMC member I add you to the
jakarta-admin group.

There are three users for you in Jira (ozeigermann,
[EMAIL PROTECTED] and [EMAIL PROTECTED]). Which one is your
login?


Great. ozeigermann is my new user. I am both jakarta committer and PMC member.

Thanks in advance

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to I set JIRA issues to resolved?


Thanks!

2006/7/13, Henri Yandell [EMAIL PROTECTED]:

Done.

On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:
 2006/7/13, Henri Yandell [EMAIL PROTECTED]:
  On 7/13/06, Thomas Dudziak [EMAIL PROTECTED] wrote:
   On 7/13/06, Oliver Zeigermann [EMAIL PROTECTED] wrote:
  
How do I get those additional rights?
  
   Usually the project owner/admin gives them. Though, for the commons
   projects there appears to be a specific user Jakarta Commons
   Developers for administering the projects. You should probably ask
   Henri about that.
 
  Nah, that user is a side-effect of a user pulled over from Bugzilla.
  We've kept it at the moment for project leads. Some of them anyway.
 
  For additional rights you just need to ask. The rules I abide by are
  that if you're a jakarta committer, I add you to the jakarta-developer
  group and if you're a jakarta PMC member I add you to the
  jakarta-admin group.
 
  There are three users for you in Jira (ozeigermann,
  [EMAIL PROTECTED] and [EMAIL PROTECTED]). Which one is your
  login?

 Great. ozeigermann is my new user. I am both jakarta committer and PMC member.

 Thanks in advance

 Oliver

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRANSACTION-5) [transaction] GenericLockManager constructor ignores LoggerFacade argument

 [ http://issues.apache.org/jira/browse/TRANSACTION-5?page=all ]
 
Oliver Zeigermann resolved TRANSACTION-5:
-

Resolution: Invalid

This is intended behavior. It is used to have a specific logger for the lock
manager.

 [transaction] GenericLockManager constructor ignores LoggerFacade argument
 --

  Key: TRANSACTION-5
  URL: http://issues.apache.org/jira/browse/TRANSACTION-5
  Project: Commons Transaction
 Type: Bug

 Versions: 1.1.0
  Environment: Operating System: All
 Platform: All
 Reporter: Ky Vong


 In the following constructor for GenericLockManager, the LoggerFacade
 argument is ignored and a new LoggerFacade is always created.  Thus, the
 LoggerFacade that I'm passing in is never used.  This affects the
 subclasses of GenericLockManager as well since they all call this
 constructor.  Someone probably just did this temporarily for some debugging 
 and
 forgot to set this.logger back to the LoggerFacade argument.
 Can this be fixed for 1.1?
 Thanks,
 Ky Vong
 public GenericLockManager(int maxLockLevel, LoggerFacade logger, long
 timeoutMSecs,
 long checkThreshholdMSecs) throws IllegalArgumentException {
 if (maxLockLevel  1)
 throw new IllegalArgumentException(The maximum lock level must be
 at least 1 (
 + maxLockLevel +  was specified));
 this.maxLockLevel = maxLockLevel;
 this.logger = logger.createLogger(Locking);
 this.globalTimeoutMSecs = timeoutMSecs;
 this.checkThreshhold = checkThreshholdMSecs;
 }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRANSACTION-8) [transaction] TransactionalMapWrapper doesn't work correctly with null values

 [ http://issues.apache.org/jira/browse/TRANSACTION-8?page=all ]
 
Oliver Zeigermann resolved TRANSACTION-8:
-

Resolution: Fixed

Patch applied. Thanks!

 [transaction] TransactionalMapWrapper doesn't work correctly with null values
 -

  Key: TRANSACTION-8
  URL: http://issues.apache.org/jira/browse/TRANSACTION-8
  Project: Commons Transaction
 Type: Bug

  Environment: Operating System: All
 Platform: All
 Reporter: Greg Steckman
 Priority: Critical
  Attachments: TransactionalMapWrapper.patch

 TransactionalMapWrapper has a number of instances of incorrect behavior if a
 null value is placed into the Map. This is a result of using 
 Map.get(key)!=null
 (or similar) instead of Map.containsKey(key) to check if the underlying Map 
 has
 a key/value pair set or not. TransactionalMapWrapper.containsKey(key) also
 returned incorrect values if the key mapped to a null value.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TRANSACTION-6) [transaction] Timeout is not passed in org.apache.commons.transaction.locking.GenericLockManager#lock(Object ownerId, Object resourceId, int targetLockLevel, boolean r

 [ http://issues.apache.org/jira/browse/TRANSACTION-6?page=all ]
 
Oliver Zeigermann resolved TRANSACTION-6:
-

Resolution: Fixed

Bug fixed. Thanks for reporting!

 [transaction] Timeout is not passed in 
 org.apache.commons.transaction.locking.GenericLockManager#lock(Object 
 ownerId, Object resourceId, int targetLockLevel, boolean reentrant, long 
 timeoutMSecs)
 ---

  Key: TRANSACTION-6
  URL: http://issues.apache.org/jira/browse/TRANSACTION-6
  Project: Commons Transaction
 Type: Bug

 Versions: 1.1 Final
  Environment: Operating System: All
 Platform: All
 Reporter: Mathieu Baudier


 The timeOutMSecs argument is not passed in the lock(Object ownerId, Object
 resourceId, int targetLockLevel, boolean reentrant, long timeoutMSecs) method 
 of
 GenericLocakManager, as can be seen below:
 public void lock(Object ownerId, Object resourceId, int targetLockLevel, 
 boolean
 reentrant,
 long timeoutMSecs) throws LockException {
 lock(ownerId, resourceId, targetLockLevel, reentrant ?
 GenericLock.COMPATIBILITY_REENTRANT
 : GenericLock.COMPATIBILITY_NONE, false, globalTimeoutMSecs);
 }
 globalTimeoutMSecs will therefore be used instead. It is set in the 
 constructor
 init(int maxLockLevel, LoggerFacade logger, long timeoutMSecs,long
 checkThreshholdMSecs).
 In the case we faced, we were using the init(int maxLockLevel, LoggerFacade
 logger) constructor, so the timeout value is always DEFAULT_TIMEOUT (that is
 3 ms) and we have no way to configure it externally without changing our 
 own
 code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager

[ 
http://issues.apache.org/jira/browse/TRANSACTION-9?page=comments#action_12420931
 ] 

Oliver Zeigermann commented on TRANSACTION-9:
-

Peter, is this still a valid request? 

 [transaction] Add full file management capabilities to the FileResourceManager
 --

  Key: TRANSACTION-9
  URL: http://issues.apache.org/jira/browse/TRANSACTION-9
  Project: Commons Transaction
 Type: Improvement

  Environment: Operating System: All
 Platform: All
 Reporter: Peter Fassev
 Priority: Minor


 Hi,
 As stated in the doc the FileResourceManager is:
 A resource manager for streamable objects stored in a file system
 I agree, that this is a resource manager, but it could be easily extended, to 
 support a full file management system. It will be very helpful to have 
 additional methods like renameResource(), getResourceSize(), 
 getResourceTime(), 
 setResourceTime() etc. This are common file operations, which should be 
 managed 
 by the FileResourceManager.
 Further it will be very helpful to have (real) support for resource 
 collections 
 (folders). It will be necessary to distinguish between single resources 
 (files) 
 and collections (folders). 
 Together, this features will enable a transactional access to any file based 
 resources - for instance a document repository.
 Are there plans for such extensions and if not, will they actually fit in the 
 goals of the transaction library?
 If not, please open the underlying structure, like the inner class 
 TransactionContext, in order to add extensions the file management. For 
 instance, it will be good to have a separate factory method, which creates 
 the 
 context.
 If you are interested in this proposal, I am ready to contribute to this 
 project. I consider myself as an experienced java developer and I will be 
 glad 
 to help you. 
 Best regards
 Peter Fassev

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Release plan?


Excatly! That's just what I was proposing in my last email!

Would you want to assist?

Hihi

Oliver

2006/7/13, Henri Yandell [EMAIL PROTECTED]:

Is the aim to have a 1.2 release of transaction at some point?

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] Release plan?