svn commit: r1159409 - /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/javascript/StackExtension.java

2011-08-18 Thread hlship
Author: hlship
Date: Thu Aug 18 20:42:39 2011
New Revision: 1159409

URL: http://svn.apache.org/viewvc?rev=1159409&view=rev
Log:
Add a toString() to StackExtension

Modified:

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/javascript/StackExtension.java

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/javascript/StackExtension.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/javascript/StackExtension.java?rev=1159409&r1=1159408&r2=1159409&view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/javascript/StackExtension.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/javascript/StackExtension.java
 Thu Aug 18 20:42:39 2011
@@ -16,16 +16,20 @@ package org.apache.tapestry5.services.ja
 
 /**
  * A contribution to an extensible {@link JavaScriptStack}. Such a stack is 
created in terms of all the contributions.
- * 
- * @since 5.3
+ *
  * @see ExtensibleJavaScriptStack
+ * @since 5.3
  */
 public class StackExtension
 {
-/** The type of extension. */
+/**
+ * The type of extension.
+ */
 public final StackExtensionType type;
 
-/** The value contributed; will have symbols expanded, then be converted 
to the appropriate type. */
+/**
+ * The value contributed; will have symbols expanded, then be converted to 
the appropriate type.
+ */
 public final String value;
 
 public StackExtension(StackExtensionType type, String value)
@@ -34,4 +38,10 @@ public class StackExtension
 this.value = value;
 }
 
+@Override
+public String toString()
+{
+return String.format("StackExtension[%s %s]", type.name(), value);
+}
+
 }




svn commit: r1159364 - /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/TapestryAppInitializer.java

2011-08-18 Thread drobiazko
Author: drobiazko
Date: Thu Aug 18 19:20:18 2011
New Revision: 1159364

URL: http://svn.apache.org/viewvc?rev=1159364&view=rev
Log:
Printing Tapestry 5 in ascii code when the registry startup is announced.

Modified:

tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/TapestryAppInitializer.java

Modified: 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/TapestryAppInitializer.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/TapestryAppInitializer.java?rev=1159364&r1=1159363&r2=1159364&view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/TapestryAppInitializer.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/TapestryAppInitializer.java
 Thu Aug 18 19:20:18 2011
@@ -21,7 +21,11 @@ import org.apache.tapestry5.ioc.Registry
 import org.apache.tapestry5.ioc.def.ContributionDef;
 import org.apache.tapestry5.ioc.def.ModuleDef;
 import org.apache.tapestry5.ioc.internal.util.InternalUtils;
-import org.apache.tapestry5.ioc.services.*;
+import org.apache.tapestry5.ioc.services.ServiceActivity;
+import org.apache.tapestry5.ioc.services.ServiceActivityScoreboard;
+import org.apache.tapestry5.ioc.services.Status;
+import org.apache.tapestry5.ioc.services.SymbolProvider;
+import org.apache.tapestry5.ioc.services.SymbolSource;
 import org.apache.tapestry5.services.TapestryModule;
 import org.slf4j.Logger;
 
@@ -57,14 +61,14 @@ public class TapestryAppInitializer
 
 /**
  * @param logger
- *logger for output confirmation
+ * logger for output confirmation
  * @param appPackage
- *root package name to search for pages and components
+ * root package name to search for pages and components
  * @param appName
- *the name of the application (i.e., the name of the 
application servlet)
+ * the name of the application (i.e., the name of the application 
servlet)
  * @param aliasMode
- *ignored (was used in 5.2)
- * @deprecated Use {@link #TapestryAppInitializer(Logger,String,String)} 
instead. To be removed
+ * ignored (was used in 5.2)
+ * @deprecated Use {@link #TapestryAppInitializer(Logger, String, String)} 
instead. To be removed
  * in 5.4.
  */
 public TapestryAppInitializer(Logger logger, String appPackage, String 
appName, String aliasMode)
@@ -74,11 +78,11 @@ public class TapestryAppInitializer
 
 /**
  * @param logger
- *logger for output confirmation
+ * logger for output confirmation
  * @param appPackage
- *root package name to search for pages and components
+ * root package name to search for pages and components
  * @param appName
- *the name of the application (i.e., the name of the 
application servlet)
+ * the name of the application (i.e., the name of the application 
servlet)
  */
 public TapestryAppInitializer(Logger logger, String appPackage, String 
appName)
 {
@@ -88,41 +92,41 @@ public class TapestryAppInitializer
 
 /**
  * @param logger
- *logger for output confirmation
+ * logger for output confirmation
  * @param appProvider
- *provides symbols for the application (normally, from the 
ServletContext init
- *parameters)
+ * provides symbols for the application (normally, from the 
ServletContext init
+ * parameters)
  * @param appName
- *the name of the application (i.e., the name of the 
application servlet)
+ * the name of the application (i.e., the name of the application 
servlet)
  * @param aliasMode
- *ignored (was used in 5.2 and earlier)
+ * ignored (was used in 5.2 and earlier)
  * @param executionModes
- *an optional, comma-separated list of execution modes, each 
of which is used
- *to find a list of additional module classes to load (key
- *tapestry.name-modules in appProvider, 
i.e., the servlet
- *context)
- * @deprecated Use {@link 
#TapestryAppInitializer(Logger,SymbolProvider,String,String)} instead.
+ * an optional, comma-separated list of execution modes, each of 
which is used
+ * to find a list of additional module classes to load (key
+ * tapestry.name-modules in appProvider, 
i.e., the servlet
+ * context)
+ * @deprecated Use {@link #TapestryAppInitializer(Logger, SymbolProvider, 
String, String)} instead.
  * To be removed in 5.4.
  */
 public TapestryAppInitializer(Logger logger, Sym

[jira] [Closed] (TAP5-1605) Template parsing of expansions can't handle map expressions

2011-08-18 Thread Robert Zeigler (JIRA)

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

Robert Zeigler closed TAP5-1605.


   Resolution: Fixed
Fix Version/s: 5.3

> Template parsing of expansions can't handle map expressions
> ---
>
> Key: TAP5-1605
> URL: https://issues.apache.org/jira/browse/TAP5-1605
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Robert Zeigler
>Assignee: Robert Zeigler
> Fix For: 5.3
>
>
> 5.3 introduced map support into the property expression language in the form: 
> {'foo': 'bar'}.
> Expansion parsing chokes on the syntax, however.  It uses a reluctant regular 
> expression to find the closing brace:
> private static final Pattern EXPANSION_PATTERN = 
> Pattern.compile("\\$\\{\\s*(.*?)\\s*}");
> Which means that the use of a map inside an expansion prematurely terminates 
> the exansion:
> ${echoMap({"foo": "bar"})}
> The regex finds the first } and the expression evaluates as:
> echoMap({"foo": "bar"
> Which is clearly incorrect.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Reopened] (TAP5-1605) Template parsing of expansions can't handle map expressions

2011-08-18 Thread Robert Zeigler (JIRA)

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

Robert Zeigler reopened TAP5-1605:
--


re-open to set the fix version.

> Template parsing of expansions can't handle map expressions
> ---
>
> Key: TAP5-1605
> URL: https://issues.apache.org/jira/browse/TAP5-1605
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Robert Zeigler
>Assignee: Robert Zeigler
>
> 5.3 introduced map support into the property expression language in the form: 
> {'foo': 'bar'}.
> Expansion parsing chokes on the syntax, however.  It uses a reluctant regular 
> expression to find the closing brace:
> private static final Pattern EXPANSION_PATTERN = 
> Pattern.compile("\\$\\{\\s*(.*?)\\s*}");
> Which means that the use of a map inside an expansion prematurely terminates 
> the exansion:
> ${echoMap({"foo": "bar"})}
> The regex finds the first } and the expression evaluates as:
> echoMap({"foo": "bar"
> Which is clearly incorrect.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TAP5-1366) Tapestry must honor the position of added tags in the relative to the tags, for IE compatibility

2011-08-18 Thread Bob Harner (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087172#comment-13087172
 ] 

Bob Harner commented on TAP5-1366:
--

Although this issue is now fixed for Tapestry 5.3, Tapestry 5.2 users still 
need a solution for the IE Compatibility Mode issue. I just wanted to add that 
I have found success with the simple code described by Wulf Wechsung at 
http://tapestry.1045711.n5.nabble.com/t5-adding-http-header-td3369097.html -- 
it works perfectly for setting the IE Compatibility Mode header.

> Tapestry must honor the position of added tags in the  relative to the 
>  tags, for IE compatibility
> --
>
> Key: TAP5-1366
> URL: https://issues.apache.org/jira/browse/TAP5-1366
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-core
>Affects Versions: 5.3, 5.2
>Reporter: Ville Virtanen
>Assignee: Howard M. Lewis Ship
> Fix For: 5.3
>
>
> This problem was discussed with Thiago on mailing list, reference to it:
> http://tapestry.1045711.n5.nabble.com/X-UA-Compatible-amp-IE-9-td4406801.html
> In short, the following was agreed on:
> "Wouldn't Tapestry reordering  elements come in the , ,   
> everything else order be sufficient?"
> Old description:
> As Microsoft documentation states 
> (http://msdn.microsoft.com/en-us/library/cc817574.aspx) the META tags that 
> direct IE8 must be positioned as follows: "The X-UA-compatible header is not 
> case sensitive; however, it must appear in the Web page's header (the HEAD 
> section) before all other elements, except for the TITLE element and other 
> META elements.".
> The most flexible solution would be to honor the order of META and other tags 
> that author has put directly to the template: the place for T5 tags could be 
> indicated with special tag:
> For an example 
> 
>   
>  My Web Page
>   
>   
>   
>   
>   .
>   .
> If author decides to omit the t:headcontent tag then T5 would not attach any 
> meta or link tags.
> Other solution as Howard indicated in the mailing list would be to just add 
> the T5 specific stuff to the end of the head section. 
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TAP5-1504) on GAE Tapestry will crash on startup if tapestry-upload is on the classpath.

2011-08-18 Thread Robert Zeigler (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087159#comment-13087159
 ] 

Robert Zeigler commented on TAP5-1504:
--

So, on GAE, with your custom implementation of FileItemFactory, you don't need 
the UploadSymbols.REPOSITORY_LOCATION, correct?  As an alternative workaround, 
why not supply the system property yourself? I haven't used GAE, really, so I 
don't know if specifying -Dupload.repository-location=gae.dummy.location is 
reasonable or not, but there should also be a point early enough in the IOC 
registry bootstrapping process that would allow you to 
System.setProperty(...,...).  At least as a temporary workaround. 


> on GAE Tapestry will crash on startup if tapestry-upload is on the classpath.
> -
>
> Key: TAP5-1504
> URL: https://issues.apache.org/jira/browse/TAP5-1504
> Project: Tapestry 5
>  Issue Type: Bug
>  Components: tapestry-upload
>Affects Versions: 5.2.5
>Reporter: Alejandro Scandroli
> Attachments: TAP5-1504.patch
>
>
> I'm trying to deploy a tapestry project to GAE. Everything seems to work fine 
> except for tapestry-upload. In fact the application will crash on startup if 
> the tapestry-upload library is on the classpath, even when I contribute my 
> own GAE compatible FileItemFactory.
> After a little bit of digging I found the offending line in UploadModule:
> configuration.add(UploadSymbols.REPOSITORY_LOCATION, 
> System.getProperty("java.io.tmpdir"));
> This line will throw a NPE when System.getProperty("java.io.tmpdir") returns 
> NULL. I couldn't find any quick workarounds without having to touch the 
> UploadModule code, that's why I'm filing this issue.
> My naïve attempt to fix this is to use:
> String tmpdir = System.getProperty("java.io.tmpdir");
> if (tmpdir != null) configuration.add(UploadSymbols.REPOSITORY_LOCATION, 
> tmpdir);
> But I don't know If I should consider other scenarios. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (TAP5-1570) More javascript events for zones

2011-08-18 Thread Robert Zeigler (JIRA)

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

Robert Zeigler updated TAP5-1570:
-

Issue Type: Improvement  (was: Bug)

This isn't really a bug.  It's not that Tapestry isn't working correctly, it's 
that you'd like to see the existing functionality expanded, so this is an 
improvement.

> More javascript events for zones
> 
>
> Key: TAP5-1570
> URL: https://issues.apache.org/jira/browse/TAP5-1570
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.1.0.0, 5.1, 5.0.16
>Reporter: Joe Klecko
>
> It seems that time and time again for each T5 project (6 out of 7 so far) I 
> find I need to override tapesty.js methods to add additional support for 
> zones.  Currently there is only 1 event fired from a zone 
> (Tapestry.ZONE_UPDATED_EVENT), I'd like to suggest/request there be at least 
> 4 events total (3 new ones):
> 1) ZONE_BEFORE_AJAX_REQUEST_EVENT:  This would be fired before the ajax 
> request is sent to the server.  Listeners should be able to cancel the ajax 
> request (similiar to the way tapestry allows a form submission to be canceled)
> 2) ZONE_BEFORE_UPDATE_EVENT:  This would be fired after the ajax request 
> returns and just before the zone is updated via the processReply() method.  
> Again, listeners should be able to cancel the update.
> 3) ZONE_UPDATED_EVENT:  already and is listed here for completeness.
> 4) ZONE_AJAX_REQUEST_ERROR_EVENT:  This would be fired if the ajax request 
> errored out for the zone. (includes error data) 
> references to mailing list: 
> http://tapestry.1045711.n5.nabble.com/More-javscript-zone-events-please-td4401005.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[CONF] Apache Tapestry > Environmental Services

2011-08-18 Thread confluence







Environmental Services
Page edited by DEMEY Emmanuel


 Changes (1)
 




...
The @[Environmental|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Environmental.html] annotation, when used in a component class, causes the associated field to be replaced at runtime with a read-only value obtained from an Environment service provided by an enclosing component.  
A very common Environmental is [_javascript_Support|http://http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/_javascript_/_javascript_Support.html], [_javascript_Support|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/_javascript_/_javascript_Support.html], used when generating [client-side _javascript_|_javascript_]. 
 {code:java} 
...


Full Content

Environmental Services

Environmental services represent yet another, distinct form of injection.

Unlike service injection (injection via a service implementation's constructor) or normal component injection (directly into component fields, via the @Inject annotation) where the injected value is always the same, with environmental services, the injected value is very late bound and dynamic.

Environmental services provide a conduit of communication between two components (usually a component and the components it encloses).  The first component pushes an object of a certain type into the environment, and then the second component can access that object merely by defining an annotated property of the same type.

An example of how this works is Tapestry's built-in form support. The Form component creates an object of type FormSupport and pushes it into the environment. Then, the enclosed form components can use that FormSupport object to participate in both the rendering of the Form and the Form's eventual submission. This is how control names and client-side ids are determined, how fields register callbacks so that they can process their part of the submission, and how fields hook themselves to client-side validation.

Using the @Environmental annotation

The @Environmental annotation, when used in a component class, causes the associated field to be replaced at runtime with a read-only value obtained from an Environment service provided by an enclosing component.

A very common Environmental is _javascript_Support, used when generating client-side _javascript_.




  @Inject @Path("${tapestry.scriptaculous}/dragdrop.js")
  private Asset dragDropLibrary;

  @Environmental
  private _javascript_Support _javascript_Support;

  void setupRender()
  {
_javascript_Support.importJavaScriptLibrary(dragDropLibrary);
  }




Environmental services are, by their nature, per-thread (and therefore per-request).

Accessing an environmental field causes a lookup, by type, against the Environment service.

Normally, an environmental of the specified type must be available in the Environment, or an exception is thrown when accessing the field. However, if the value of the Environmental annotation's value is false, then the environmental value is optional.

Placing a value in the environment

The Environment service has push() and pop() methods to put a value in the Environment, and discard it.

For example, say you were building a tab-based menu system and you needed to allow an outer TabGroup component to communicate with inner Tab components, to control various aspects of presentation.

The relevant information could be exposed as an interface, TabModel.



public class TabGroup
{
  @Inject
  private Environment environment;

  void beginRender()
  {
 environment.push(TabModel.class, new TabModelImpl(...));
  }

  void afterRender()
  {
environment.pop(TabModel.class);
  }
}

public class Tab
{
  @Environmental
  private TabModel model;

  void beginRender(MarkupWriter writer)
  {
...
  }
}



Notice that when pushing a value into the Environment, you identify its type as well as the instance. Environment maintains a number of stacks, one for each type. Thus, pushing a TabModel into the environment won't disturb the RenderSupport or other environmentals already there.

What's important here is that the code that pushes a environmental onto a stack should also pop it off.

The enclosed class, Tab, has full access to whatever object was pushed onto the stack by the TabGroup.

The reason why Environment is a stack is so that a component can, when it makes sense, easily replace or intercept access to an Environmental.

Fundamental Environmentals

Not all environmentals are pushed into the Environment by components.

A number of environmentals are initialized as part of page rendering, even before the first component starts to render. This initialization is accomplished with Ma

[CONF] Apache Tapestry > Environmental Services

2011-08-18 Thread confluence







Environmental Services
Page edited by DEMEY Emmanuel


 Changes (5)
 




...
The @[Environmental|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Environmental.html] annotation, when used in a component class, causes the associated field to be replaced at runtime with a read-only value obtained from an Environment service provided by an enclosing component.  
A very common Environmental is [RenderSupport|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/RenderSupport.html], [_javascript_Support|http://http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/_javascript_/_javascript_Support.html], used when generating [client-side _javascript_|_javascript_]. 
 {code:java} 
...
   @Environmental 
  private RenderSupport renderSupport; 
  private _javascript_Support _javascript_Support; 
   void setupRender()   { 
renderSupport.addScriptLink(dragDropLibrary); _javascript_Support.importJavaScriptLibrary(dragDropLibrary); 
  }  
...
Not all environmentals are pushed into the Environment by components.  
A number of environmentals are initialized as part of page rendering, even before the first component starts to render. This initialization is accomplished with [MarkupRendererFilter|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/MarkupRendererFilter.html] contributions to the [MarkupRenderer|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/MarkupRenderer.html] service. 
 h1. Accessing Environmentals in Services 
...


Full Content

Environmental Services

Environmental services represent yet another, distinct form of injection.

Unlike service injection (injection via a service implementation's constructor) or normal component injection (directly into component fields, via the @Inject annotation) where the injected value is always the same, with environmental services, the injected value is very late bound and dynamic.

Environmental services provide a conduit of communication between two components (usually a component and the components it encloses).  The first component pushes an object of a certain type into the environment, and then the second component can access that object merely by defining an annotated property of the same type.

An example of how this works is Tapestry's built-in form support. The Form component creates an object of type FormSupport and pushes it into the environment. Then, the enclosed form components can use that FormSupport object to participate in both the rendering of the Form and the Form's eventual submission. This is how control names and client-side ids are determined, how fields register callbacks so that they can process their part of the submission, and how fields hook themselves to client-side validation.

Using the @Environmental annotation

The @Environmental annotation, when used in a component class, causes the associated field to be replaced at runtime with a read-only value obtained from an Environment service provided by an enclosing component.

A very common Environmental is _javascript_Support, used when generating client-side _javascript_.




  @Inject @Path("${tapestry.scriptaculous}/dragdrop.js")
  private Asset dragDropLibrary;

  @Environmental
  private _javascript_Support _javascript_Support;

  void setupRender()
  {
_javascript_Support.importJavaScriptLibrary(dragDropLibrary);
  }




Environmental services are, by their nature, per-thread (and therefore per-request).

Accessing an environmental field causes a lookup, by type, against the Environment service.

Normally, an environmental of the specified type must be available in the Environment, or an exception is thrown when accessing the field. However, if the value of the Environmental annotation's value is false, then the environmental value is optional.

Placing a value in the environment

The Environment service has push() and pop() methods to put a value in the Environment, and discard it.

For example, say you were building a tab-based menu system and you needed to allow an outer TabGroup component to communicate with inner Tab components, to control various aspects of presentation.

The relevant information could be exposed as an interface, TabModel.



public class TabGroup
{
  @Inject
  private Environment environment;

  void beginRender()
  {
 environment.push(TabModel.class, new TabModelImpl(...));
  }

  void afterRender()
  {
environment.pop(TabModel.class);
  }
}

public class Tab
{
  @Environmental
  private TabModel model;

  void beginRender(MarkupWriter writer)
  {
...
  }
}


svn commit: r1159201 - in /tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5: internal/jpa/PersistenceContentHandler.java internal/jpa/PersistenceUnitInfoImpl.java jpa/TapestryP

2011-08-18 Thread drobiazko
Author: drobiazko
Date: Thu Aug 18 13:01:18 2011
New Revision: 1159201

URL: http://svn.apache.org/viewvc?rev=1159201&view=rev
Log:
Persistence unit parser now also checks for jar file urls

Modified:

tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/PersistenceContentHandler.java

tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/PersistenceUnitInfoImpl.java

tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/jpa/TapestryPersistenceUnitInfo.java

Modified: 
tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/PersistenceContentHandler.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/PersistenceContentHandler.java?rev=1159201&r1=1159200&r2=1159201&view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/PersistenceContentHandler.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/PersistenceContentHandler.java
 Thu Aug 18 13:01:18 2011
@@ -113,25 +113,36 @@ public class PersistenceContentHandler i
 if (ELEMENT_PROVIDER.equals(localName))
 {
 persistenceUnitInfo.persistenceProviderClassName(string);
-} else if (ELEMENT_CLASS.equals(localName))
+}
+else if (ELEMENT_CLASS.equals(localName))
 {
 persistenceUnitInfo.addManagedClassName(string);
-} else if (ELEMENT_CACHING.equals(localName))
+}
+else if (ELEMENT_CACHING.equals(localName))
 {
 
persistenceUnitInfo.sharedCacheMode(toEnum(SharedCacheMode.class, string));
-} else if (ELEMENT_VALIDATION_MODE.equals(localName))
+}
+else if (ELEMENT_VALIDATION_MODE.equals(localName))
 {
 
persistenceUnitInfo.validationMode(toEnum(ValidationMode.class, string));
-} else if (ELEMENT_MAPPING_FILE.equals(localName))
+}
+else if (ELEMENT_MAPPING_FILE.equals(localName))
 {
 persistenceUnitInfo.addMappingFileName(string);
-} else if (ELEMENT_NON_JTA_DATA_SOURCE.equals(localName))
+}
+else if (ELEMENT_JAR_FILE.equals(localName))
+{
+persistenceUnitInfo.addJarFileUrl(string);
+}
+else if (ELEMENT_NON_JTA_DATA_SOURCE.equals(localName))
 {
 persistenceUnitInfo.nonJtaDataSource(string);
-} else if (ELEMENT_JTA_DATA_SOURCE.equals(localName))
+}
+else if (ELEMENT_JTA_DATA_SOURCE.equals(localName))
 {
 persistenceUnitInfo.jtaDataSource(string);
-} else if (ELEMENT_PERSISTENCE_UNIT.equals(localName))
+}
+else if (ELEMENT_PERSISTENCE_UNIT.equals(localName))
 {
 if (persistenceUnitInfo != null)
 {

Modified: 
tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/PersistenceUnitInfoImpl.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/PersistenceUnitInfoImpl.java?rev=1159201&r1=1159200&r2=1159201&view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/PersistenceUnitInfoImpl.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/PersistenceUnitInfoImpl.java
 Thu Aug 18 13:01:18 2011
@@ -25,6 +25,7 @@ import javax.persistence.ValidationMode;
 import javax.persistence.spi.ClassTransformer;
 import javax.persistence.spi.PersistenceUnitTransactionType;
 import javax.sql.DataSource;
+import java.net.MalformedURLException;
 import java.net.URL;
 import java.util.Arrays;
 import java.util.Collections;
@@ -56,6 +57,8 @@ public class PersistenceUnitInfoImpl imp
 
 private final Set mappingFilesNames = CollectionFactory.newSet();
 
+private final List jarFileUrls = CollectionFactory.newList();
+
 private final Properties properties = new Properties();
 
 
@@ -163,6 +166,34 @@ public class PersistenceUnitInfoImpl imp
 
 }
 
+/**
+ * {@inheritDoc}
+ */
+public TapestryPersistenceUnitInfo addJarFileUrl(URL url)
+{
+jarFileUrls.add(url);
+
+return this;
+}
+
+/**
+ * {@inheritDoc}
+ */
+public TapestryPersistenceUnitInfo addJarFileUrl(String url)
+{
+try
+{
+return addJarFileUrl(new URL(getPersistenceUnitRootUrl(), url));
+} catch (MalformedURLException e)
+{
+ 

svn commit: r1159194 - in /tapestry/tapestry5/trunk/tapestry-jpa/src: main/java/org/apache/tapestry5/internal/jpa/ test/java/org/apache/tapestry5/internal/jpa/ test/resources/

2011-08-18 Thread drobiazko
Author: drobiazko
Date: Thu Aug 18 12:41:53 2011
New Revision: 1159194

URL: http://svn.apache.org/viewvc?rev=1159194&view=rev
Log:
Throw an exception if multiple persistence units are configured to include 
unlisted classes

Added:

tapestry/tapestry5/trunk/tapestry-jpa/src/test/java/org/apache/tapestry5/internal/jpa/EntityManagerSourceImplTest.java

tapestry/tapestry5/trunk/tapestry-jpa/src/test/resources/multiple-persistence-units-include-unlisted-classes.xml
  - copied, changed from r1159181, 
tapestry/tapestry5/trunk/tapestry-jpa/src/test/resources/single-persistence-unit.xml
Modified:

tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/EntityManagerSourceImpl.java

Modified: 
tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/EntityManagerSourceImpl.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/EntityManagerSourceImpl.java?rev=1159194&r1=1159193&r2=1159194&view=diff
==
--- 
tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/EntityManagerSourceImpl.java
 (original)
+++ 
tapestry/tapestry5/trunk/tapestry-jpa/src/main/java/org/apache/tapestry5/internal/jpa/EntityManagerSourceImpl.java
 Thu Aug 18 12:41:53 2011
@@ -28,6 +28,9 @@ import javax.persistence.spi.Persistence
 import javax.persistence.spi.PersistenceProviderResolverHolder;
 import javax.persistence.spi.PersistenceUnitInfo;
 
+import org.apache.tapestry5.func.F;
+import org.apache.tapestry5.func.Mapper;
+import org.apache.tapestry5.func.Predicate;
 import org.apache.tapestry5.ioc.Resource;
 import org.apache.tapestry5.ioc.internal.util.CollectionFactory;
 import org.apache.tapestry5.ioc.internal.util.InternalUtils;
@@ -55,16 +58,50 @@ public class EntityManagerSourceImpl imp
 
 List persistenceUnitInfos = 
parsePersistenceUnitInfos(persistenceDescriptor);
 
- final Map remainingConfigurations 
= configure(configuration, persistenceUnitInfos);
+final Map remainingConfigurations = 
configure(configuration, persistenceUnitInfos);
 
 configureRemaining(persistenceUnitInfos, remainingConfigurations);
 
-if(persistenceUnitInfos.size() == 1)
+if(persistenceUnitInfos.size() == 1) 
+{
 
packageNamePersistenceUnitConfigurer.configure(persistenceUnitInfos.get(0));
+}
+else
+{
+validateUnitInfos(persistenceUnitInfos);
+}
 
 this.persistenceUnitInfos = persistenceUnitInfos;
 }
 
+private void validateUnitInfos(List 
persistenceUnitInfos)
+{
+final List affectedUnits = 
F.flow(persistenceUnitInfos).filter(new Predicate()
+{
+public boolean accept(TapestryPersistenceUnitInfo info)
+{
+return !info.excludeUnlistedClasses();
+}
+}).map(new Mapper()
+{
+public String map(TapestryPersistenceUnitInfo info)
+{
+return info.getPersistenceUnitName();
+}
+}).toList();
+
+if(0 < affectedUnits.size())
+{
+throw new RuntimeException(
+String.format(
+"Persistence units '%s' are configured to include 
managed classes that have not been explicitly listed. " +
+"This is forbidden when multiple persistence units 
are used in the same application. " +
+"Please configure persistence units to exclude 
unlisted managed classes (e.g. by removing  element) 
" +
+"and include them explicitly.",
+InternalUtils.join(affectedUnits)));
+}
+}
+
 private List 
parsePersistenceUnitInfos(Resource persistenceDescriptor)
 {
 List persistenceUnitInfos = 
CollectionFactory.newList();

Added: 
tapestry/tapestry5/trunk/tapestry-jpa/src/test/java/org/apache/tapestry5/internal/jpa/EntityManagerSourceImplTest.java
URL: 
http://svn.apache.org/viewvc/tapestry/tapestry5/trunk/tapestry-jpa/src/test/java/org/apache/tapestry5/internal/jpa/EntityManagerSourceImplTest.java?rev=1159194&view=auto
==
--- 
tapestry/tapestry5/trunk/tapestry-jpa/src/test/java/org/apache/tapestry5/internal/jpa/EntityManagerSourceImplTest.java
 (added)
+++ 
tapestry/tapestry5/trunk/tapestry-jpa/src/test/java/org/apache/tapestry5/internal/jpa/EntityManagerSourceImplTest.java
 Thu Aug 18 12:41:53 2011
@@ -0,0 +1,51 @@
+// Copyright 2011 The Apache Software Foundation
+//
+// Licensed under the Apache License, Version 2.0 (the "License");
+// you may not use this file except in compliance with the License.
+// You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+/

[jira] [Commented] (TAP5-1558) FormFragment should allow more fine grained control over when to be considered "invisible"

2011-08-18 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086865#comment-13086865
 ] 

Hudson commented on TAP5-1558:
--

Integrated in tapestry-trunk-freestyle #488 (See 
[https://builds.apache.org/job/tapestry-trunk-freestyle/488/])
TAP5-1558: FormFragment should allow more fine grained control over when to 
be considered "invisible"

robertdzeigler : 
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1159019
Files : 
* 
/tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/FormFragmentExplicitVisibleBoundsDemo.java
* 
/tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/pages/Index.java
* 
/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/FormFragment.java
* 
/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/ClientBehaviorSupportImpl.java
* 
/tapestry/tapestry5/trunk/tapestry-core/src/main/resources/org/apache/tapestry5/tapestry.js
* 
/tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/AjaxTests.java
* 
/tapestry/tapestry5/trunk/tapestry-core/src/test/app1/FormFragmentExplicitVisibleBoundsDemo.tml
* 
/tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/services/ClientBehaviorSupport.java
* 
/tapestry/tapestry5/trunk/tapestry-core/src/test/java/org/apache/tapestry5/integration/app1/FormTests.java
* 
/tapestry/tapestry5/trunk/tapestry-test/src/main/java/org/apache/tapestry5/test/SeleniumTestCase.java
* 
/tapestry/tapestry5/trunk/tapestry-core/src/main/resources/org/apache/tapestry5/t5-formfragment.js


> FormFragment should allow more fine grained control over when to be 
> considered "invisible"
> --
>
> Key: TAP5-1558
> URL: https://issues.apache.org/jira/browse/TAP5-1558
> Project: Tapestry 5
>  Issue Type: Improvement
>  Components: tapestry-core
>Affects Versions: 5.3
>Reporter: Robert Zeigler
>Assignee: Robert Zeigler
>Priority: Minor
> Fix For: 5.3
>
>
> The 5.2 line of Tapestry introduced the "alwaysSubmit" parameter to form 
> fragment.  This is nice because it allows the fragment to be submitted even 
> if hidden.  However, it doesn't cover all use cases.  Consider a situation 
> like:
> 
>... validate="required".../>
>... validate="required".../>
>
> 
> User reveals tab 1, then reveals the form fragment on tab1 and makes changes. 
> Now user reveals tab2. Note that the fragment on tab1 is still revealed in 
> the context of tab1, but the entire tab1 is hidden.  There is currently no 
> way to make it so that "submit" will submit the information from the 
> formfragment in both tabs and behave correctly in all situations. I will 
> enumerate.  Some definitions for clarity:
> fragmentX is the fragment on tabX. 
> fragmentX visibility refers to the state of the actual fragment, rather than 
> the state of the containing tab.  So if fragment1 is visible, it means it's 
> visible when tab1 is active... and I am considering it visible when tab2 is 
> active, even though the entire tab1 is invisible.
> 1) If "alwaysSubmit" is false and fragment1 is invisible, you will get the 
> correct behavior regardless of tab1/tab2 visibility
> 2) If "alwaysSubmit" is false and fragment1 is visible, you will get the 
> correct behavior iff tab1 is active.  If tab2 is active, fragment1's fields 
> will not be submitted.
> 3) If "alwaysSubmit" is true and fragment1 is invisible, you will get 
> incorrect behavior (well, technically, it's "correct": the information will 
> be submitted, as per alwaysSubmit, but this is a case where you don't 
> actually /want/ the information submitted if the fragment isn't visible)
> 4) If "alwaysSubmit" is true and fragment is visible, you will get correct 
> behavior.
> You can conditionally "alwaysSubmit": alwaysSubmit on the same condition for 
> visibility as the "visible" trigger.  The problem here comes in the following 
> scenario:
> User opens a page with fragment1 initially visible, but no data yet in the 
> required field.  User marks fragment1 as invisible. User submits the form.  
> The submission will fail because "alwaysSubmit" was true at the time the form 
> rendered.
> The culprit behind this is Tapestry's "isDeepVisible" method.  It searches 
> for visibility up to the point where it finds a form element.  But in the 
> case above, the form element contains the tab divs, so the fragment is 
> determined to be invisible and the data not submitted for the inactive tab, 
> even if the user clicked on the trigger to make the fragment visible while 
> the tab was active.
> This is something of an edge c

[jira] [Updated] (TAP5-411) A persistence strategy to provide page state that persists until the user navigates away from the page

2011-08-18 Thread Robert Zeigler (JIRA)

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

Robert Zeigler updated TAP5-411:


Summary: A persistence strategy to provide page state that persists until 
the user navigates away from the page  (was: A persistence strategy to provide 
page specific state )

> A persistence strategy to provide page state that persists until the user 
> navigates away from the page
> --
>
> Key: TAP5-411
> URL: https://issues.apache.org/jira/browse/TAP5-411
> Project: Tapestry 5
>  Issue Type: New Feature
>  Components: tapestry-core
>Affects Versions: 5.1
>Reporter: Peter Stavrinides
>  Labels: tapestr5-review-for-closing
>
> Perhaps the most commonly reoccurring  persistence pattern is 'per page', as 
> opposed to session wide, or per request. Tapestry provides persistence 
> strategies for the later of these, but there is no strategy that mirrors a 
> pages 'implied' life-cycle. 
> @Persist
> Persists a value for a page for the duration of a session: best used on 
> primitives, a disadvantage is that its open for abuse by incorrect use which 
> will clutter the session and increase its size thereby reducing scalability.
> @Persist("flash")
> A persisted object is removed after a post: - Not suited to all use cases 
> that require 'page specific' persistence... render methods can sometimes 
> prevent using flash persistence.
> Currently the most scalable pattern for simulating page state is using 
> onActivate with onPassivate, and re-instantiating objects required for the 
> page, generally from their identifiers.   
> It requires more boilerplate code for checking that URL parameters are passed 
> correctly, particularly for pages that have 'optional parameters'... the 
> downside is more queries and having to use identifiers in URL parameters.
> @Persist("conversation")
> Seam provides this type of strategy, conversations provide a generally better 
> persistence context, persistence is associated to a single window / tab, for 
> which it retains state information between data requests/posts etc (whereas 
> its relatives, which are other windows or tabs will be independent to the 
> 'conversation') . Conversational state has been discussed in the past for 
> Tapestry.
> @Persist("?")
> The proposed strategy is along the same lines as conversational state, but 
> persisted values are retained for all instances of that page (regardless of 
> tabs or windows, meaning in practice that all active instances of that page 
> share an identifier), so closing all instances would remove associated 
> persisted values.
> More on this in this thread here:
> http://www.nabble.com/Persistance-td20732003.html#a20732003

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TAP5-411) A persistence strategy to provide page specific state

2011-08-18 Thread Robert Zeigler (JIRA)

[ 
https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086854#comment-13086854
 ] 

Robert Zeigler commented on TAP5-411:
-

I think the issue is still valid.  The addition of the session attribute 
feature doesn't change the value of this request.  At the core, this issue is 
asking for a new page-level persistence strategy that retains the values until 
the user navigates away from the page.  Session attributes are 
application-wide, and they exist until you explicitly remove them.  Adding the 
new persistence strategy would make it much easier to deal with Tapestry's 
redirects after actionlinks/evenlinks/posts.

The tricky part of this issue is determining what defines "navigating away from 
the page".

Suppose I have two tabs or windows open to the same page and I navigate away 
from the page in one of the tabs/windows? What then?
Does closing a tab count as navigating away from the page? What if two tabs are 
open to the same page and I close one of the tabs?

If a viable solution can be found to the navigation problem, this is worth 
implementing. 

> A persistence strategy to provide page specific state 
> --
>
> Key: TAP5-411
> URL: https://issues.apache.org/jira/browse/TAP5-411
> Project: Tapestry 5
>  Issue Type: New Feature
>  Components: tapestry-core
>Affects Versions: 5.1
>Reporter: Peter Stavrinides
>  Labels: tapestr5-review-for-closing
>
> Perhaps the most commonly reoccurring  persistence pattern is 'per page', as 
> opposed to session wide, or per request. Tapestry provides persistence 
> strategies for the later of these, but there is no strategy that mirrors a 
> pages 'implied' life-cycle. 
> @Persist
> Persists a value for a page for the duration of a session: best used on 
> primitives, a disadvantage is that its open for abuse by incorrect use which 
> will clutter the session and increase its size thereby reducing scalability.
> @Persist("flash")
> A persisted object is removed after a post: - Not suited to all use cases 
> that require 'page specific' persistence... render methods can sometimes 
> prevent using flash persistence.
> Currently the most scalable pattern for simulating page state is using 
> onActivate with onPassivate, and re-instantiating objects required for the 
> page, generally from their identifiers.   
> It requires more boilerplate code for checking that URL parameters are passed 
> correctly, particularly for pages that have 'optional parameters'... the 
> downside is more queries and having to use identifiers in URL parameters.
> @Persist("conversation")
> Seam provides this type of strategy, conversations provide a generally better 
> persistence context, persistence is associated to a single window / tab, for 
> which it retains state information between data requests/posts etc (whereas 
> its relatives, which are other windows or tabs will be independent to the 
> 'conversation') . Conversational state has been discussed in the past for 
> Tapestry.
> @Persist("?")
> The proposed strategy is along the same lines as conversational state, but 
> persisted values are retained for all instances of that page (regardless of 
> tabs or windows, meaning in practice that all active instances of that page 
> share an identifier), so closing all instances would remove associated 
> persisted values.
> More on this in this thread here:
> http://www.nabble.com/Persistance-td20732003.html#a20732003

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira