-
1. Re: Difference in JBoss startup and deploy of application
digdas.seam.digdas.nl Nov 19, 2009 1:44 PM (in response to digdas.seam.digdas.nl)Note: When placing the war in
deploy/deploy.last
it works as if deployed later. -
2. Re: Difference in JBoss startup and deploy of application
digdas.seam.digdas.nl Nov 19, 2009 2:27 PM (in response to digdas.seam.digdas.nl)Note 2: I just thought of this.
When the application was deployed, and later another application is deployed, it stops working as well.
We do include the libraries of seam etc. in the standard lib folder of the JBoss server, and not in the packages themself. Perhaps that causes some of the problems we observe?
Or, how to do it then? -
3. Re: Difference in JBoss startup and deploy of application
kapitanpetko Nov 20, 2009 2:33 AM (in response to digdas.seam.digdas.nl)Maybe your jobs starts executing before Seam is initialized? What is the scope of your job class?
-
4. Re: Difference in JBoss startup and deploy of application
digdas.seam.digdas.nl Nov 20, 2009 7:12 AM (in response to digdas.seam.digdas.nl)Scope of the job class is application. Also is the scope of the scheduler (which starts it)
The scheduler is run after initialization of seam - the trigger org.jboss.seam.postInitialization
What I think caused the problem is that I have the seam jar files in the lib folder of jboss - not in the project.
When deploying another application after this one the job starts to produce the above error.
-
5. Re: Difference in JBoss startup and deploy of application
kapitanpetko Nov 20, 2009 8:15 AM (in response to digdas.seam.digdas.nl)
Aart Scheepers wrote on Nov 20, 2009 07:12:
Scope of the job class is application. Also is the scope of the scheduler (which starts it)So you are not using a persistent job store (database)?
What I think caused the problem is that I have the seam jar files in the lib folder of jboss - not in the project.
When deploying another application after this one the job starts to produce the above error.
Why do you have them in the lib folder? You are usually better off using classloading isolation, so that you are sure every application uses its own libraries. Read more here
-
6. Re: Difference in JBoss startup and deploy of application
digdas.seam.digdas.nl Nov 20, 2009 8:55 AM (in response to digdas.seam.digdas.nl)I am using a job which updates database.
Why the files in the lib folder:
- Smaller apps
- When updating them, all can be done at once.I will have a look at your page. Looks interesting.
-
7. Re: Difference in JBoss startup and deploy of application
kapitanpetko Nov 20, 2009 9:11 AM (in response to digdas.seam.digdas.nl)
Aart Scheepers wrote on Nov 20, 2009 08:55:
I am using a job which updates database.I meant the jobs themselves saved in the database. But if you are following the link you posted, you probably aren't (it has RAMJobStore configured)
Why the files in the lib folder:
- Smaller apps
- When updating them, all can be done at once.Are you really OK with updating all of your applications at once? Smaller apps is a valid point, but I am not sure if this is a supported configuration.
-
8. Re: Difference in JBoss startup and deploy of application
digdas.seam.digdas.nl Nov 20, 2009 7:25 PM (in response to digdas.seam.digdas.nl)
I meant the jobs themselves saved in the database. But if you are following the link you posted, you probably aren't (it has RAMJobStore configured)You are right, the jobs are not saved in the database but the class has the code it should execute. It does database updates when necessary.
Are you really OK with updating all of your applications at once? Smaller apps is a valid point, but I am not sure if this is a supported configuration.Yes, I am OK updating all the applications at once. It had advantages and disadvantages though.
One problem I ran into was that the s:graphicalImage tag was not working any more.
What I did was to split the project into a update-project (no GUI) and the edit project.