Oliver Zeigermann oliver at zeigermann.de writes:
I am proposing to strip Commons Transaction to its very core.
Deleted:
- no more XA classes: We really can not an implement an XA resource
with the existing implementation
Hi Oliver,
reducing ctx to a core is a good idea. I only would not
Rahul Akolkar rahul.akolkar at gmail.com writes:
We still do:
http://jakarta.apache.org/commons/releases/versioning.html
Regarding deprecation: It is considered a fully compatible change. So you can
actually deprecate at any point and don't need to postpone it a next release of
a particular
Jochen Wiedmann jochen.wiedmann at gmail.com writes:
The problem is simply that votes for releases on commons drive me sick.
It is not the exception, but the standard, that people demand changes
(which they of course assume that the RM will do) and use a -1 to
enforce their opinion.
I
Dennis Thrysøe dth at conscius.com writes:
I am unsure how resource enlistment to the TransactionManager should
work, as mentioned in a comment in jira. For now the collections enlist
themselves, when created. What's the best way to go about this? I guess
there must be some j2ee-mandated
Phil Steitz phil.steitz at gmail.com writes:
a) no source, binary or semantic incompatibilities or deprecations
introduced in a x.y.z release
I really wonder what's the problem with deprecations since they don't have any
influence on compatibility. I'd guess there is always a reason for
Niall Pemberton niall.pemberton at gmail.com writes:
Can't remember if I did or not - anyway I've added a download target
to the ant build
http://svn.apache.org/viewvc?view=revrevision=521856
Hi Niall,
missed that one completely up to now. Thanks very much. I'm going to drop the
jars from
Torsten Curdt tcurdt at apache.org writes:
As already announced I would like to move
http://jakarta.apache.org/commons/sandbox/jci/
out of the sandbox so I can then prepare a first RC. Please cast your
votes for the graduation!
Despite the result already posted:
+1
Joerg
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
Oliver Zeigermann ozeigermann at apache.org writes:
Jakarta Commons Transaction 1.2 has been released.
Finally :)
Oliver
(on behalf of the Jakarta community)
Thanks, Oliver.
Joerg
-
To unsubscribe, e-mail: [EMAIL
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
I will modify the code in the 1.x branch ASAP.
That was fast :)
Would you please add the JMX approach to the 2.0 Wiki page as a cool idea?
Added.
Regards
Joerg
-
To
Author: joerg
Date: Tue Mar 20 14:15:48 2007
New Revision: 520602
URL: http://svn.apache.org/viewvc?view=revrev=520602
Log:
replace the geronimo spec jars compiled by me at least with the now officially
released ones
(this is only a temporary solution as long as we don't have an Ant
Niall Pemberton niall.pemberton at gmail.com writes:
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.
+1 I'd like to see the release without any further delays. I'll address the Jar
issue as fast as possible, but
David Blevins david.blevins at visi.com writes:
Anyway, I've applied your changes, built and verified each of them
work with JDK 1.3, and put them all up for a vote on geronimo dev.
I'm not sure what the status of your efforts are, but at the very
least you'll be able to use them next
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
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
Joerg Heinicke joerg.heinicke at gmx.de writes:
... splitting it into commons-cvs|svn|scm at jakarta.apache.org,
commons-jira|issues|bugs at jakarta.apache.org and the actual dev list for
discussions ...
I just wanted to ping on this one [1]. There seems to be much agreement about
splitting
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
Craig McClanahan craigmcc at apache.org writes:
Someone had asked earlier about how Commons projects accomplished this goal
before Maven. The answer was a convention for using Ant build.xml scripts
that referenced a series of build.properties files containing definitions
for things like what
David Blevins david.blevins at visi.com writes:
Only passively reading the thread, but from some of the comments and
your commit message it looks like you just need JDK 1.3 compiled
versions of those specs.
Yes, that's it.
I'd be happy to apply your pom changes in the geronimo tree and
Simon Kitching skitching at apache.org writes:
When using maven, only the first run needs to download the jars ... So, no
need
for internet access at build time.
For ant ... This can be run *once* to download the jars, but is not part of
the
main build task, so there is no need for
David Blevins david.blevins at visi.com writes:
If someone needs JDK 1.3 versions of any spec jar, I'd be happy to
help. OpenJPA had a similar request recently (JDK 1.3 version of JTA
1.1) and I made sure to do the final release of that spec with JDK 1.3.
What exactly do you have in mind
Rahul Akolkar rahul.akolkar at gmail.com writes:
URL: http://svn.apache.org/viewvc?view=revrev=494203
snip/
This change warrants a major release for [transaction].
Really? I don't mind if the current code is release as 2.0. But for such a minor
change (though in the interface)? Please find
Craig McClanahan craigmcc at apache.org writes:
Storing JAR files in your source repository (or pretty much any other
scenario where you check in things that have been generated, instead of
rebuilding them) has the following negative impacts:
* Bypasses the normal mechanisms people use to
Simon Kitching skitching at apache.org writes:
For a start, if every project were to do this, the impact on the
Apache SVN repository would be huge.
Cocoon (maintenance branch 2.1) has currently 111 jars with about 40 MB in its
repository (+ the one for the environment [2]), we are regularly
Adam Jack ajack at apache.org writes:
Project commons-transaction has an issue affecting its community integration.
This issue affects 20 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
Will have a look on this.
Jörg
Martin Cooper martinc at apache.org writes:
In general I don't like the need for internet access on build time.
This is a red herring. One way or another, you're going to have to get the
jars from the network, whether it's getting them from SVN, or having Maven
or Ant retrieve them. And in
Niall Pemberton niall.pemberton at gmail.com writes:
The ant build only seems to work for JDK 1.3 when the geronimo jars
are overriden with the sun ones and doesn't work for me for JDK 1.4
Yes, it stands and fails with the correct jee jars as I wrote recently [1].
(tests fail because it
Henri Yandell flamefew at gmail.com writes:
The spam issue is a tricky decision. Sometimes I turn off the
notifications to then do a lot of changes, other times I let the spam
hit the list because moving an issue into a version is a decision. If
there were a lot of them, I'd be tempted to
Joerg Heinicke joerg.heinicke at gmx.de writes:
The ant build only seems to work for JDK 1.3 when the geronimo jars
are overriden with the sun ones and doesn't work for me for JDK 1.4
Yes, it stands and fails with the correct jee jars as I wrote recently [1].
Works now with 1.3 compiled
Niall Pemberton niall.pemberton at gmail.com writes:
Since RC3 was created (back in July 2006!) there is now the new
Source Header and Copyright Notice Policy that needs to be complied
with: http://www.apache.org/legal/src-headers.html
Henri fixed this in the trunk for transaction a few
Martin Cooper martinc at apache.org writes:
Any exact targetting for unresolved issues will lead to this
issues hasn't made it into the latest release, we try to get it into the
next one mails polluting the mailing lists without nearly any additional
value.
I think that is a good
+1 welcome!
Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Henri Yandell flamefew at gmail.com writes:
The aim is to provide us with information on where projects are
release-wise and where we are in terms of answering new issues. Some
of our components aren't there - for example Jelly which has 77
unversioned issues and Attributes/Discovery which
Henri Yandell flamefew at gmail.com writes:
I would like to be added to jakarta-developers as well.
Done.
Thanks, Hen.
Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hello,
when playing around with commons transaction I did a test compile with
JDK 1.3. I wonder if we can still claim that 1.3 is the minimum requirement.
One bug in the build.xml I fixed already [1]. But you still can't
compile commons transaction with JDK 1.3 as it fails for
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
To release 1.2 final based on that release candidate here is my
+1
Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 8/28/06, Kris Nuttycombe Kris.Nuttycombe at noaa.gov wrote:
Another new-committer question:
Are special privileges required to change the status of issues in JIRA?
There are a few outstanding issues in [pipeline] that can now be closed.
This is an issue not yet covered in the new
Torsten Curdt tcurdt at apache.org writes:
I really wonder why this should be a concern of the actual component at all.
A component is an encapsulated piece of software with a well-defined
interface (here API). If there are problems in the environment in using this
component or looking it
Stephen Colebourne scolebourne at btopenworld.com writes:
PROPOSAL:
The major version number of a component, where it is greater than 1,
shall be included in the package name.
I really wonder why this should be a concern of the actual component at all. A
component is an encapsulated piece of
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
Finally there is the third release candidate at
http://people.apache.org/~ozeigermann/tx-1.2rc3/
Hi Oliver,
just wondering: What happened to the release?
Cheers,
Jörg
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
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
Also what is the minimum JDK version for transaction?
I used ant for the previous releases (target package). Minimum jdk is 1.2
Has anybody actually been checking this? Setting those properties has probably
influence on the compiler
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
That certainly is post 1.2, right? Maybe even some work for a 2.0
version?
Yes, definitely after the current release process. We can decide whether it gets
1.3 or 2.0 or what else, when we have the code :)
Hmmm. Why do you need
Niall Pemberton niall.pemberton at gmail.com writes:
Has anybody actually been checking this?
I just tried compiling using JDK 1.3
Thanks.
So it seem that for JDK 1.3 the only real issue is in FileResourceManager.
It was me who introduced it :) Fixed it ...
Another thing I noticed
to incompatibilities if the methods for
transactional concern are called on the ResourceManager interface and not on the
FileResourceManager instance.
P.S.: I think it might be the time for a 1.2 release. What do you think?
See other thread ...
Jörg
2006/7/13, Joerg Heinicke joerg.heinicke
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
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:
I came across some further problems with the transactional FileResourceManager
and the XAResource implementation.
Simple deletes of resources did not get applied for me. Debugging showed that no
commit was triggered.
The reason: deleteResource() and createResource() in FileResourceManager were
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
The reason: deleteResource() and createResource() in FileResourceManager
were assumed as being read-only (TransactionContext.readOnly not set to
false).
Hard to believe, but this really seems to be true. A fix should be
simple,
Long time ago I mentioned a problem with the usage of the transaction ids as
directory name [1]. This problem resulted from JOTM using colon as part of an
Xid. For easier subclassing I created a patch at [2], so that all references to
this directory are collected at one place
Another strange things in commits, this time the latest 3 commits to FileHelper:
1. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/transaction/trunk/
src/java/org/apache/commons/transaction/util/FileHelper.java
?rev=349996r1=155433r2=349996diff_format=h
Shouldn't it be
if ( !
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
To me it seems generatedUniqueTxId does exactly as advertised in
Javadocs. Don't you agree?
No. :) This dismisses my argument about externally generated ids, yes. But two
different threads calling generateUniqueTxId() at the same time
Cservenak Tamas cservenak at is-micro.hu writes:
The generatedUniqueTxId() method in FileResourceManager uses
System.currentTimeMillis() to generate txId's.
On my system it causes duplicate txId generation and FRM failure. I have
4 threads accessing one FRM instance.
This simple patch
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
But even more, may understanding is that the user will never see an
XAResource and will never try to get an instance of it. It simply is
an interface between the transaction manager of your container and
your resource manager.
Ok, this
Hello,
there seems to be some inconsistency in the implementation of AbstractXAResource
regarding TMJOIN in the start() method. The first thing that is checked for in
this method is getCurrentlyActiveTransactionalResource() != null and a
XAException is thrown if there is a currently active
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
there seems to be some inconsistency in the implementation of
AbstractXAResource regarding TMJOIN in the start() method. The first thing
that is checked for in this method is
getCurrentlyActiveTransactionalResource() != null and a
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
Hmmm. I do not understand you either.
:)
I have certainly read the XA spec, but - of course - am not entirely sure that
my implementation is free of errors.
I did not know that it was you implementing it. And about the errors: that's
When following the JTA 1.0.1B spec [1] while implementing my resource adapter
(XAResource) around the Commons Transaction FileResourceManager I came across
another issue:
XAResource has a method public Xid[] recover(int flag). Following is written
in the spec's section 3.4.8 Failures recovery:
Oliver Zeigermann oliver.zeigermann at gmail.com writes:
1. Commons transaction is not prepared for JNDI.
Honestly, I have no idea what this is all about. Could you explain?
Hello Oliver,
to be honest I do neither know that much about it. My impression was that most
of the JTA transaction
Hello,
I now implement the XAResource wrapper for commons transaction and came across
two issues:
1. Commons transaction is not prepared for JNDI. This is probably not a must,
but most of the containers seem to work with JNDI. When trying it that way I get
the following exception:
Hello,
I saw that commons transaction provides an implementation of transactional file
access and an abstract implementation of javax.transaction.xa.XAResource. Now I
wonder why these two are not combined and the transactional file access
implementation does not exist as a XAResource. Is it so
to
add it.
Not yet :)
Jörg
2005/10/28, Joerg Heinicke joerg.heinicke at gmx.de:
I saw that commons transaction provides an implementation of transactional
file access and an abstract implementation of
javax.transaction.xa.XAResource.
Now I wonder why these two are not combined
Any suggestion how to handle that otherwise?
Continueing this topic in the other thread 'Handling compilation errors':
http://marc.theaimsgroup.com/?t=11245564832r=1w=4
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Torsten Curdt tcurdt at apache.org writes:
(BTW, this use case shows a different lifecycle for the handler and
is another signal for removing lifecycle specific stuff from the handler
interface.)
Well, to me it's a clear example why a
lifecycle would make sense!
Of course, but it
Torsten Curdt tcurdt at apache.org writes:
I think we are facing two questions:
1. Keep the ProblemHandler across compilations (and add a lifecycle) or
re-create the object
Hmm, this also depends :) For the error counter there is no problem to create
one on every compilation cycle. But
Torsten Curdt tcurdt at apache.org writes:
1. Keep the ProblemHandler across compilations (and add a
lifecycle) or re-create the object
Hmm, this also depends :) For the error counter there is no problem
to create one on every compilation cycle.
You mean create counter object??
Don Brown donald.brown at gmail.com writes:
As I integrate jci into Struts Ti, I'm faced with how to display the
compilation errors to the user. What general strategy does Cocoon or
any other web framework use to do this? The asynchronous nature of
the compiler makes it difficult to display
My use case is a development mode for Struts Ti. One of the key
features I'm going for in this mode is the ability to modify the
source code, the refresh your browser to see the changes. For
example, if the user added an action method, but they made a typo that
would cause the compilation
http://www.cafeaulait.org/oldnews/news2005August17.html
JSR 199 seems to be nearly three years old. Not much result to see :-)
Their analogy to the CompilationProblem handling: a DiagnosticListener (like our
CompilationProblemHandler) with just one method problemFound(DiagnosticMessage)
with
Torsten Curdt tcurdt at apache.org writes:
Another interesting interface might be JavaFileObject hiding the
details of
accessing resources. Though JCI has ResourceReader and
ResourceStore it is not
really detached from file system.
Huh? Why not? The memory implementations
don't
Torsten Curdt tcurdt at apache.org writes:
Huh? Why not? The memory implementations
don't care much of the file system :-P
That was one of the main goal of JCI.
Yes and that's fine. But search for the String.replace(char, char)
method and
you know what I mean There are many
http://issues.apache.org/bugzilla/show_bug.cgi?id=36261
wait a sec ...let's discuss that on the list first.
while I agree that it makes sense to remove
the counting from the problem handler interface
I am not too sure I like the other changes too much.
Off-list you talked about
http://issues.apache.org/bugzilla/show_bug.cgi?id=36261
wait a sec ...let's discuss that on the list first.
while I agree that it makes sense to remove
the counting from the problem handler interface
I am not too sure I like the other changes too much.
We could also make use of a factory
Torsten Curdt tcurdt at apache.org writes:
I have a problem with loading a class immediately after the setup
of the CompilingClassLoader. With a setup like in the TestCases using a
signal object it does not work (I get ClassNotFoundException), because the
CCL does release a reload()
Hello,
today I came across an issue with the Janino version 2.3.3 in use in JCI. It
does not find static methods in classes. After an update to 2.3.8 (which
unfortunately needs adaptions in JaninoJavaCompiler the compilation of my
classes work again. Is there any interest in this update to JCI
After an update to 2.3.8 (which unfortunately needs adaptions in
JaninoJavaCompiler the compilation of my classes work again. Is there any
interest in this update to JCI codebase?
Of course! ...what a question ;)
There is just the problem of the incompatible change, i.e. JCI does no
Hello,
I have a problem with loading a class immediately after the setup of the
CompilingClassLoader. With a setup like in the TestCases using a signal object
it does not work (I get ClassNotFoundException), because the CCL does release a
reload() event immediately after setup - before my files
Mike Bowler wrote:
I've added a second patch to the bug which fixes more checkstyle
warnings. I'm still not sure why the patches were being discarded from
my emails this morning so I'm just playing it safe and putting them in
bugzilla.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16429
78 matches
Mail list logo
