Patches sent through the mailing list are OK too, as long as the author makes
it clear that it's
intended for inclusion. Larger pieces of work need separate handling. JIRA used
to have a checkbox
that allowed the uploader to explicitly mark a patch as intended for inclusion,
thus allowing us to
I just took a quick look (but not tested) at your code, and I don't see how not
caching a proxy has any difference.
Since the PlasticProxyFactory calls createObject() upon every method call.
I just tested a simple app with two PUs on the same page and it works fine.
I still say this is not an iss
Patch with tests is even better.
On Nov 14, 2012, at 8:12 AM, Lenny Primak wrote:
> That's still not a patch. Patches look like this:
>
> http://guide.macports.org/chunked/development.patches.html
>
> If you attach that to the JIRA you have a better chance of someone looking at
> it.
>
> On
That's still not a patch. Patches look like this:
http://guide.macports.org/chunked/development.patches.html
If you attach that to the JIRA you have a better chance of someone looking at
it.
On Nov 13, 2012, at 8:37 PM, John wrote:
> I got the original source code from tapestry-jpa version 5.
please see https://issues.apache.org/jira/browse/TAP5-2027
- Original Message -
From: Lenny Primak
To: Tapestry development
Sent: Wednesday, November 14, 2012 1:21 AM
Subject: Re: PATCH: tapestry-jpa EntityManagerObjectProvider fixes entities
not associated with correct entity
I got the original source code from tapestry-jpa version 5.3.6 which I see is
not registered in the JIRA, so I can't report this bug. Perhaps this is only in
this version, I will try another.
It is more like a refactor as provided.
As a patch
removethe private EntityManager proxy line
remov
I didn't look at this in detail, but proxies are sometimes thread-local, and
not really singletons.
Also, your patch isn't a real patch. it's a replacement, and harder to
incorporate for committers,
if it is indeed necessary.
On Nov 13, 2012, at 8:09 PM, John wrote:
> Hi,
>
> The original cod
Hi,
The original code is like below, note how the proxy provided acts like a
singleton. I'll take a look at the JIRA, thanks.
public class EntityManagerObjectProvider implements ObjectProvider
{
private EntityManager proxy;
public T provide(final Class objectType, final AnnotationProvid
I am not sure why the existing code doesn't work for you as it works fine in my
environment.
Another thing is that patches belong in JIRA and cannot be taken from mailing
lists due to copyright issues.
Perhaps Igor can shed some light on this?
On Nov 13, 2012, at 7:48 PM, "John" wrote:
> I
I put this on the users group recently to complete a thread, it belongs here
really I suppose.
The problem manifests when multiple PUs are defined in persistence.xml and
then referred to in classes using the @PersistenceContext(unitName=
annotation. As it is in 5.3.6 the first EntityManager wi
Additional methods are easy, and not incompatible. I say just stick with the
original Cookie interface.
On Nov 13, 2012, at 9:59 AM, Ulrich Stärk wrote:
> The Cookies interface and implementation can use some love. I'll take care of
> that. Do we want to
> simply add a new method to the interf
1. Pass ComponentMessagesSource and ThreadLocale to the YesNoTranslator
constructor
2.
public String toClient(Boolean flag) {
Messages messages =
messagesSource.getApplicationCatalog(threadLocale.getLocale());
return (flag ? messages.get("boolean.true") :
messages.get("boolean.false");
}
I added the updated patches to
https://issues.apache.org/jira/browse/TAP5-1394 - but Jira did not ask
me for some license stuff.
The Cookies interface and implementation can use some love. I'll take care of
that. Do we want to
simply add a new method to the interface or should we create Cooki
Hello,
I need to create a Boolean translator to display boolean field value as a
localized text (yes/oui/..., no/non/...)
I have added my translator into AppModile.java class.
/public static void contributeTranslatorSource(MappedConfiguration configuration) {
configuration.add(Boolean.class, n
Hi,
i've just checked the tapestry project out from the git repo of ASF
and building Tapestry 5 using "$ gradle build"
results with
gradle build --stacktrace
Dynamic properties are deprecated:
http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html
Deprecated dyna
On Tue, 13 Nov 2012 12:59:55 -0200, Ulrich Stärk wrote:
The Cookies interface and implementation can use some love. I'll take
care of that. Do we want to
simply add a new method to the interface or should we create Cookies2
for backward compatibility?
In this case, as I guess very few peop
The Cookies interface and implementation can use some love. I'll take care of
that. Do we want to
simply add a new method to the interface or should we create Cookies2 for
backward compatibility?
I tend to Cookies2.
Uli
On 13.11.2012 14:51, Michael Wyraz wrote:
> From a54fdc541054a4fad654f31b0
Michael,
Thank you for the patch! It is wonderful to see people from the community
stepping up with these kinds of fixes and improvements.
Alas, we can't use the patch if provided via the email list; per Apache
guidelines, all patches must be added as attachments to a JIRA issue. This
gives you
From a54fdc541054a4fad654f31b0467b315812effd9 Tue, 13 Nov 2012 14:51:08
+0100
From: Michael Wyraz
Date: Tue, 13 Nov 2012 14:40:22 +0100
Subject: [PATCH] TAP5-1858 Cookie service should allow to set path,
domain AND maxAge
diff --git
a/tapestry-core/src/main/java/org/apache/tapestry5/internal
From 38237c181334aa28dec7394755732cb19353f4b5 Tue, 13 Nov 2012 14:49:46
+0100
From: Michael Wyraz
Date: Tue, 13 Nov 2012 14:37:57 +0100
Subject: [PATCH] TAP5-1027 DatePicker component: "None", "Today" buttons
localisation
diff --git
a/tapestry-core/src/main/java/org/apache/tapestry5/corelib/
20 matches
Mail list logo
