[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1839) Use HSQL to store Quartz jobs when deployed on JBoss AS
by Michael Yuan (JIRA)
Use HSQL to store Quartz jobs when deployed on JBoss AS
-------------------------------------------------------
Key: JBSEAM-1839
URL: http://jira.jboss.com/jira/browse/JBSEAM-1839
Project: JBoss Seam
Issue Type: Feature Request
Reporter: Michael Yuan
Assigned To: Michael Yuan
Fix For: 2.0.0.GA
Right now, Quartz jobs are stored "in-memory" and hence cannot be auto-started when the server reboots. The user can use persistence job stores by using a custom quartz property file. However, in JBoss AS, we should store jobs in the HSQL DB by default:
* In the dispatcher component, we can have a "jboss=true" attribute
* If this attribute is true, the QuartzDispatcher will setup Quartz tables for this particular app in the HSQL at startup, and then use the HSQL DB as persistent job store.
This way, when the application deploys again, all the jobs for this application will be auto-started again.
--
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
[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
[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
[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