October 2010 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1869) Example of Control Set for Quartz SEAM Interation

by Piergiuseppe Spinelli (JIRA)

Example of Control Set for Quartz SEAM Interation ------------------------------------------------- Key: JBSEAM-1869 URL: http://jira.jboss.com/jira/browse/JBSEAM-1869 Project: JBoss Seam Issue Type: Task Components: Examples Affects Versions: 2.0.0.BETA1 Environment: Any OS. JBoss2_0B project. Reporter: Piergiuseppe Spinelli Priority: Optional The attached sample is an attept to create a control interface to SEAM asynchronous method using Quartz as scheduling engine. I was asked to do this in the related forum thread: I am not sure it is near to the desired functionalities, but it could be used as a starting point (or possibly as a negative sample). The sample is very raw and I have used SEAM too short to be sure I did not make to stupid things, but if the idea is useful, I am sure other people will improve it. Notes: - The sample use quartz integrated in SEAM as it currently is: a support to asynchronous method - Quartz is used with its in-memory db, the persistent status is kept by the application usign custom Entities - Since I am a newby in SEAM, I preferred to make some custom classes for supporting CRUD operations since it was difficult to me to get the SEAM framework to do more that the simple things showed in the samples TODO: - it could be better to use some well known components library for the interface instead that my custom controls (i.e Trinidad) - the entities I made to keep the application status use a table schema very similar to the quartz schema: it could be a good idea in a future to be able to use some entity model over the quartz schema - it would be usefull to add the feature to upload the classes to be scheduler directly by the web interface, mayby using a classloader chain for supporting hot versioning. -- 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, 2 months

4
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-975) constraint by inclusion on remote calls object fields

by Zalder R (JIRA)

constraint by inclusion on remote calls object fields ----------------------------------------------------- Key: JBSEAM-975 URL: http://jira.jboss.com/jira/browse/JBSEAM-975 Project: JBoss Seam Issue Type: Feature Request Components: Remoting Reporter: Zalder R Assigned To: Shane Bryzak Priority: Optional I think it could be nice to define the fields of the objects returned in a "WebRemote call" with an "include" parameter (instead of the current exclude parameter). For instance : now you have : @WebRemote(exclude = {"secret"}) it would be nice to be able to define : @WebRemote(include = {"fieldIreallyNeed1", "fieldIreallyNeed2"}) The reasons for this are many : - security : if the object structure varies over time, you would not want the new fields to be available on the client side by default - in some cases it's a lot more lightweight (both in the code and in the volume of data sent) to define a minimum set of fields you want instead of the fields you don't want -- 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, 2 months

5
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-984) Progressbar for async methods

by Pete Muir (JIRA)

Progressbar for async methods ----------------------------- Key: JBSEAM-984 URL: http://jira.jboss.com/jira/browse/JBSEAM-984 Project: JBoss Seam Issue Type: Feature Request Components: Core, Remoting Affects Versions: 1.2.0.GA Reporter: Pete Muir Priority: Minor I think a fairly common use case is: * Call action * call async method to do a lengthy action * return to page * update progress bar and say when done based on async method I think we could wrap this all up: * user raises an event in the async method indicating completeness * remoting/ui component polls seam to update progress -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Resolved: (JBSEAM-280) Integrate the page context with Seam Remoting

by Shane Bryzak (JIRA)

[ https://jira.jboss.org/browse/JBSEAM-280?page=com.atlassian.jira.plugin.s... ] Shane Bryzak resolved JBSEAM-280. --------------------------------- Resolution: Out of Date > Integrate the page context with Seam Remoting > --------------------------------------------- > > Key: JBSEAM-280 > URL: https://jira.jboss.org/browse/JBSEAM-280 > Project: Seam > Issue Type: Feature Request > Components: Remoting > Reporter: Shane Bryzak > Assignee: Shane Bryzak > Fix For: The future > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Support the propogation of Seam's Page Context between remoting requests. > Functional Requirements: > * The page context should be stored client-side in the global js variable Seam.pageContext. > * The page context should be included in any Seam Remoting requests in the packet header, i.e.: > <page-context><variable name="foo"><ref id="0"/></variable>...</page-context> > * The page context should be returned by all remoting requests and replace the local copy > * The client web page should be able to manipulate the page context, changing values, adding new values, etc via Seam.pageContext, e.g. Seam.pageContext.foo = bar; > Non functional requirements: > * Add a server-side convenience method to convert an object to serialized XML > * Add a client-side convenience method to deserialize XML into an object > * Create a <pageContext/> JSF tag that will embed a <script> block into the web page that initializes the page context when the page is first loaded > * Modify the client-side remoting framework to support the dynamic discovery of object types. Use the __type field (or something similar) to identify the object type. This will mean that type stubs will not need to be explicitly imported. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (SEAMREMOTING-11) Create debug page for remoting framework

by Shane Bryzak (JIRA)

[ https://jira.jboss.org/browse/SEAMREMOTING-11?page=com.atlassian.jira.plu... ] Shane Bryzak commented on SEAMREMOTING-11: ------------------------------------------ This is still a cool idea, we should still implement it. > Create debug page for remoting framework > ---------------------------------------- > > Key: SEAMREMOTING-11 > URL: https://jira.jboss.org/browse/SEAMREMOTING-11 > Project: Seam Remoting > Issue Type: Task > Reporter: Shane Bryzak > Assignee: Shane Bryzak > Priority: Minor > Original Estimate: 2 days > Remaining Estimate: 2 days > > The remoting framework should provide a debug page that allows a user to conveniently make remoting calls to test their components. It should be accessible via a url such as /<app>/seam/remoting/debug/<componentName>. The page should list all of the remotable methods of the component, and provide an easy way of invoking each method and viewing its result. It should also allow additional context parameters (such as conversation ID) to be set for an invocation. For methods that accept complex types, collections or maps as parameters there should be an easy way for the user to specify these values. > The availability of the debug page should be controlled via a "debug" parameter in the remoting servlet configuration in web.xml, and be turned off by default. This would allow the application to be deployed in a production environment without the debug pages. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Moved: (SEAMREMOTING-11) Create debug page for remoting framework

by Shane Bryzak (JIRA)

[ https://jira.jboss.org/browse/SEAMREMOTING-11?page=com.atlassian.jira.plu... ] Shane Bryzak moved JBSEAM-151 to SEAMREMOTING-11: ------------------------------------------------- Project: Seam Remoting (was: Seam) Key: SEAMREMOTING-11 (was: JBSEAM-151) Affects Version/s: (was: 1.0 beta 2) Component/s: (was: Remoting) > Create debug page for remoting framework > ---------------------------------------- > > Key: SEAMREMOTING-11 > URL: https://jira.jboss.org/browse/SEAMREMOTING-11 > Project: Seam Remoting > Issue Type: Task > Reporter: Shane Bryzak > Assignee: Shane Bryzak > Priority: Minor > Original Estimate: 2 days > Remaining Estimate: 2 days > > The remoting framework should provide a debug page that allows a user to conveniently make remoting calls to test their components. It should be accessible via a url such as /<app>/seam/remoting/debug/<componentName>. The page should list all of the remotable methods of the component, and provide an easy way of invoking each method and viewing its result. It should also allow additional context parameters (such as conversation ID) to be set for an invocation. For methods that accept complex types, collections or maps as parameters there should be an easy way for the user to specify these values. > The availability of the debug page should be controlled via a "debug" parameter in the remoting servlet configuration in web.xml, and be turned off by default. This would allow the application to be deployed in a production environment without the debug pages. -- 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, 2 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3282) API for pluging and adding thirdparty suport to enhance Seam Remoting

by Francisco Jose Peredo Noguez (JIRA)

API for pluging and adding thirdparty suport to enhance Seam Remoting --------------------------------------------------------------------- Key: JBSEAM-3282 URL: https://jira.jboss.org/jira/browse/JBSEAM-3282 Project: Seam Issue Type: Feature Request Components: Remoting Reporter: Francisco Jose Peredo Noguez Assignee: Shane Bryzak Give us choice, expose an API to customize Seam Remoting (if it is available then it needs detailed documentation, or at least introductory documentation), so that if for some reason this never makes it in to Seam trunk, at least it becomes real easy to create some sort of plug-in to do it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
4
0 / 0

[JBoss JIRA] Resolved: (JBSEAM-3209) GWTService RPC does not transfer SerializableExceptions for GWT 1.4

by Shane Bryzak (JIRA)

[ https://jira.jboss.org/browse/JBSEAM-3209?page=com.atlassian.jira.plugin.... ] Shane Bryzak resolved JBSEAM-3209. ---------------------------------- Resolution: Out of Date GWT support in Seam 2 is now deprecated. Please refer to the Errai project instead. > GWTService RPC does not transfer SerializableExceptions for GWT 1.4 > ------------------------------------------------------------------- > > Key: JBSEAM-3209 > URL: https://jira.jboss.org/browse/JBSEAM-3209 > Project: Seam > Issue Type: Bug > Components: Remoting > Affects Versions: 2.1.0.A1 > Reporter: Adrian Stachowiak > Assignee: Shane Bryzak > Attachments: GWTService-patch.txt > > > GWTRemote is constucted in a way that it parses InvocationTargetExceptions in the processCall method. It looks for the cause of the exception and if it is a SerializableException it prepares an answer that contains the actual exception. Unfortunately in the next if statement this already prepared answer is overwritten by the standard "The call failed on the server; see server log for details" message. This way no SerializableException is ever transferred to the client. Only the standard error response. -- 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, 2 months

1
0
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2215) Interface.js too large

by Robin Young (JIRA)

Interface.js too large ---------------------- Key: JBSEAM-2215 URL: http://jira.jboss.com/jira/browse/JBSEAM-2215 Project: JBoss Seam Issue Type: Bug Components: Remoting Affects Versions: 2.0.0.GA Reporter: Robin Young Assigned To: Shane Bryzak The interface.js file produced includes type definitions for EVERY seam component in my system and takes a couple of seconds to serve. The url is "/seam/resource/remoting/interface.js?navigationSystemService" and is generated by and s:remote tag. I have added exclude parameters to my WebRemote annotations and this restricts the data sent back back but does nothing to limit the interface.js file produced. Is there any way to slim this down and thus improve the speed of my site? -- 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, 2 months

4
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1056) Comet requests for Seam Remoting

by Niels Hoogeveen (JIRA)

Comet requests for Seam Remoting -------------------------------- Key: JBSEAM-1056 URL: http://jira.jboss.com/jira/browse/JBSEAM-1056 Project: JBoss Seam Issue Type: Feature Request Components: Remoting Environment: any Reporter: Niels Hoogeveen Assigned To: Shane Bryzak Since JBossAS-4.2.0.CR1 supports Tomcat 6 a "servlet" of type CometProcessor, which allows for comet style http access, is available. In principle this would allow for a non-polling/long-polling solutions for eg. the JMS example. -- 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, 2 months

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues October 2010