[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2935) Seam Remoting/GWT1.5M2, change to 'Long' behavior (impacts Date?)
by darren hartford (JIRA)
Seam Remoting/GWT1.5M2, change to 'Long' behavior (impacts Date?)
-----------------------------------------------------------------
Key: JBSEAM-2935
URL: http://jira.jboss.com/jira/browse/JBSEAM-2935
Project: Seam
Issue Type: Bug
Components: GWT
Affects Versions: 2.1.x
Reporter: darren hartford
From: 1.5M2 announcement post -- http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thr...
" - "long" emulation. The Java language defines "long" types to be 64-bit
signed integers, whereas JavaScript only supports 64-bit floating point
numbers, which cannot accurately represent the same whole-number range as a
true "long" type. GWT 1.5 M2 transparently emulates long types properly to
more faithfully maintain Java semantics in web mode. "
Although this is from GWT 1.5M2, the risk/return of them changing this is unlikely. It appears that this also impacts Dates.
This has been tested against Seam 2.1-snapshot (4/25/2008) and GWT 1.5M2 on jboss 4.2. Other datatypes are working correctly, Long and Dates are not. This seems to only impact the RPC mechanism.
symptoms (on client side) for Long. Same symptoms for java.util.Date:
==============
getLong had a failure: com.google.gwt.core.client.JavaScriptException: (TypeError): orig has no properties
message: orig has no properties
fileName: http://dhartford:8080/sample-ejb3-gwt-client/com.domain.app.gwt.SeamEjbRe...
lineNumber: 7172
stack: java_lang_Long_parseLong__Ljava_lang_String_2I(undefined,16)@http://dhartford:8080/sample-ejb3-gwt-client/com.domain.app.gwt.SeamEjbRemote/0838C54E584391EEA8D10F2AD23CB3D5.cache.html:7172
com_google_gwt_user_client_rpc_core_java_lang_Long_1CustomFieldSerializer_instantiate__Lcom_google_gwt_user_client_rpc_SerializationStreamReader_2([object Object])@http://dhartford:8080/sample-ejb3-gwt-client/com.domain.app.gwt.SeamEjbRemote/0838C54E584391EEA8D10F2AD23CB3D5.cache.html:4258
com_domain_app_gwt_client_SeamGwtStandardDataService_1TypeSerializer_instantiate__Lcom_google_gwt_user_client_rpc_SerializationStreamReader_2Ljava_lang_String_2([object Object],"java.lang.Long/4227064769")@http://dhartford:8080/sample-ejb3-gwt-client/com.domain.app.gwt.SeamEjbRemote/0838C54E584391EEA8D10F2AD23CB3D5.cache.html:2102
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2006) Improve handling of dependencies in examples
by Pete Muir (JIRA)
Improve handling of dependencies in examples
--------------------------------------------
Key: JBSEAM-2006
URL: http://jira.jboss.com/jira/browse/JBSEAM-2006
Project: JBoss Seam
Issue Type: Task
Affects Versions: 2.0.0.CR1
Reporter: Pete Muir
Assigned To: Pete Muir
Priority: Critical
Fix For: 2.0.1.GA
Currently dependencies are just handled as before, with all dependencies copied into lib/
I propose to replace lib/ with a local maven repository (just a simple directory structure). This will only be used if present (not present in CVS, created using dependency:copy-dependencies when running dist target). The fileset's used to declare example libraries and inclusion into deployed archives will be altered to use maven ant tasks to pull in these filesets from repositories (using the local repo if present).
This requires some extensions to existing ant tasks.
A similar scheme can be used for seam-gen
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (SEAMCATCH-18) Provide exception type mapping (to deal with vendor-specific exception types)
by Dan Allen (JIRA)
Provide exception type mapping (to deal with vendor-specific exception types)
-----------------------------------------------------------------------------
Key: SEAMCATCH-18
URL: https://jira.jboss.org/browse/SEAMCATCH-18
Project: Seam Catch
Issue Type: Feature Request
Components: Core Implementation
Affects Versions: Alpha2
Reporter: Dan Allen
Assignee: Jason Porter
There are cases when the useful information about an exception is only available in an implementation-specific exception. It would be useful to provide an exception type mapping infrastructure so that implementation-specific exceptions can be mapped to portable exception types.
A classic example is JPA provider exceptions. Hibernate throws a SQLGrammarException in cases where the SQL statement is invalid (has a syntax error or refers to an invalid table/column). However, if you are writing portable JPA code, you cannot catch this exception. Thus, it would be useful to be able to catch an portable exception that represents this vendor-specific exception.
Obviously, the actual mapping in this example would be done in the persistence module. Catch needs to provide some mechanism for an integration to register the mappings, which it will honor when notifying handlers.
It should be noted that this is a very popular feature from Spring. Refer to SessionFactoryUtils for an example of the exception type mapping.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months
[JBoss JIRA] Created: (SEAMFACES-47) UIInputContainer keeps invalid state too long
by Nicklas Karlsson (JIRA)
UIInputContainer keeps invalid state too long
---------------------------------------------
Key: SEAMFACES-47
URL: https://jira.jboss.org/browse/SEAMFACES-47
Project: Seam Faces
Issue Type: Bug
Components: UI Components
Affects Versions: 3.0.0.Alpha3
Reporter: Nicklas Karlsson
Given a
<p:input>
<h:inputText value="#{credentials.username}" />
</p:input>
<p:input>
<h:inputText value="#{credentials.password}" />
</p:input>
<h:commandButton value="Login" action="#{credentials.login}" />
and a
@Model
public class Credentials {
@NotNull
private String username;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
@NotNull
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
private String password;
public void login() {
System.out.println(username);
System.out.println(password);
}
}
with
<context-param>
<param-name>javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL</param-name>
<param-value>true</param-value>
</context-param>
and a modified input.xhtml that outputs #{cc.attrs.invalid}
you submit a blank form and get "true" and correct message for both fields, then you enter a value in the second field and re-submit and the messages are correct but both fields still show true for the invalid attribute output (making it impossible to use the attr for rendered attributes if e.g. an error image)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 9 months