[JBossWS] - JBossWS 2.1 not installed properly on JBoss 4.05.GA
by ansantharam
Our app is built using JDK 1.4, during the installation of JBossWS on 4.05GA version using the script ant deploy-jboss40
prepare:
undeploy-jboss40:
[delete] Deleting directory C:\jboss-4.0.5.GA\server\default\deploy\jbossws14.sar
deploy-jboss40-ejb3:
[unzip] Expanding: C:\jbossws-native-2.0.1.GA\lib\jbossws-core-scripts.zip into C:\jboss-4.0.5.GA\bin
[copy] Copying 17 files to C:\jboss-4.0.5.GA\client
[copy] Copying 1 file to C:\jboss-4.0.5.GA\lib
[copy] Copying 5 files to C:\jboss-4.0.5.GA\server\default\lib
[mkdir] Created dir: C:\jboss-4.0.5.GA\server\default\deploy\jbossws.sar
[unjar] Expanding: C:\jbossws-native-2.0.1.GA\lib\jbossws-native40.sar into C:\jboss-4.0.5.GA\server\default\deploy\jbossws.sa
r
[mkdir] Created dir: C:\jboss-4.0.5.GA\server\default\deploy\juddi-service.sar
[unzip] Expanding: C:\jbossws-native-2.0.1.GA\lib\juddi-service.sar into C:\jboss-4.0.5.GA\server\default\deploy\juddi-service
.sar
[unzip] Expanding: C:\jbossws-native-2.0.1.GA\lib\jbossws-framework-scripts.zip into C:\jboss-4.0.5.GA\bin
[copy] Copying 3 files to C:\jboss-4.0.5.GA\client
[copy] Copying 3 files to C:\jboss-4.0.5.GA\server\default\lib
deploy-jboss40-no-ejb3:
[move] Moving 1 file to C:\jboss-4.0.5.GA\server\default\deploy\jbossws.sar\META-INF
BUILD FAILED
C:\jbossws-native-2.0.1.GA\build\build-deploy.xml:79: The following error occurred while executing this line:
C:\jbossws-native-2.0.1.GA\build\macros-deploy-native.xml:298: Warning: Could not find file C:\jboss-4.0.5.GA\server\default\deploy\jbossws.sar\META-INF\jboss-service-no-ejb3.xml to copy.
Appreciate any help on this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084524#4084524
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084524
18 years, 9 months
[JBoss Seam] - Page scope too narrow?
by IGx89
I'm using jPDL pageflows, and I've run across an annoying limitation of the page scope. Specifically, if I both access a page-scoped bean from an page action expression in a pageflow and through EL expressions on the actual page, it gets created twice: one time for the pageflow action, and another when the page starts rendering.
The reason that's an annoying limitation is because I have beans that are used just for specific pages, and it seems overkill to make them conversation-scoped when they're just used by one page. But I also need to pass some settings to the page bean, so I use an action expression in the pageflow to initialize it. That seems to be the cleanest and least-coupled way of doing things, but in order to get that to work I'm having to make my page-specific beans conversation-scoped...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084518#4084518
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084518
18 years, 9 months
[JBoss jBPM] - Re: JobExecutor, maxLockTime, and the LockMonitorThread: Wha
by jeffj55374
anonymous wrote : but IS it started?
Nope. I ran our application in the Eclipse debugger and did not see any reference to LockMonitorThread. I also generated a thread dump of our application, LockMonitorThread does not appear there either. (The dump file is 1800+ lines, I can email it to anybody that is interested in double checking)
Note that we are not using a J2EE server. We are running this as a standalone Java application.
So with respect to the comment:
anonymous wrote : Isn't this the same as transactiontimeouts work in j2ee? Roling back something that just took to long but finished without an error
Maybe so, but we aren't using this in a J2EE server. In any case, this isn't a huge issue for us at the moment since we can simply increase the maxLockTime to be the Integer.MAX_VALUE
Philosophical commentary follows (feel free to stop reading)
So here is my opinion. Any comments and feedback would be appreciated. This is mostly intended to help me understand the jBPM design intent with respect to rolling back successfully completed activities simply because they took too long.
So if the node completes succesfully, the transaction shouldn't rollback. Since the timeout doesn't cause the thread (execution context / token) to be aborted the system is doing the work anyhow. You aren't saving anything by considering it a failure. If the intent is that it should be considered an error if a sequence of nodes takes too long to process, then you probably should somehow abort the processing rather than let it continue. Now what would happen (if the LockMonitorThread is actually running) another thread would acquire the job and start running. Now you have two threads actively processing the same path. (Maybe this is a mute point since I think some of the async / JobExecutor stuff is changing post V3.2.1?)
Wouldn't be so bad if everything our process did was inside the same database and transaction and didn't have any external side affects that are either difficult or impossible to rollback. So with this behavior we somehow would need to add our own code to test for exceeding maxLockTime and that a rollback was going to occur and we would have to figure out how to detect that jBPM decided to roll things back and compensate or reverse the external actions. For example one of our steps loads millions of rows of data, impractical to have in a single transaction and rollback the data. Our code doesn't get any notification that the rollback occurred so if we have no opportunity to execute compensating code. Maybe the design intent is that everything should be done in such a manner that it is controlled by a transaction monitor. This is generally a bunch of non-trivial work for non-database related activities.
So again, I still don't see the value in having a maxLockTime for a job if you are going to let the job run to completion w/o aborting it and allow the system to attempt to process the path again even though it is still currently being processed. This could lead to all kinds of chaos.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084509#4084509
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084509
18 years, 9 months