"[EMAIL PROTECTED]" wrote : I can see the temp creation, but we can't use any changerequest to WTP 2.x at this point since that won't be out until a few months. (we can of course report it) | | But before that we need to figure out if we actually *have* an issue here....but if we have an issue all other deployers should have this issue....
I don't really understand the point you're making or what you are asking (did you read or understand my other comments in this thread ?) The purpose of this thread was to query the problem with users of JBossTool-AS. I think sufficient detail has been given in the thread so far to easily allow a 3rd party to re-create the issue. Its been cited a few times that you've been unable to observe the issue or are unable to see any temporary files in use. I've tried to be helpful and establish what maybe different by asking questions about your observation methods and configuration but got given vague answers. Unfortunately you've not provided sufficient detail to allow me to assist you to observe the problem (if you are still unable to see it). On the subject are other things broken, probably who cares about them ? I'm not trying to save the world here. I'm not in a position to be able to make any claims for all WTP deployers, but I have already reported in this thread that the WTP provided JBoss deployer appears (to me) to deploy into the "tmp0/" directory using a single file .EAR from what I have observed. That's all I can provide you with. anonymous wrote : "Darryl - are you saying all WTP deployers that can deploy to servers deploy dir are broken when it deploys across filesystems ?" Which servers deploy dir ? Across what file systems where ? There are 3 filesystems in play here, the file system your workspace is in, the file system your project is in (thats right, your project does not have to be inside your workspace tree) and the file system your runtime is in. All 3 file systems can be different. When you publish using a WTP runtime driver to Tomcat (for example) the following scenario occurs: * You save a change to a .java file, this gets saved in your project area lets say this was JavaSource/domain/MyClass.java * Eclipse this auto-compiles the class for this, and this ends inside your project areas lets say as bin/domain/MyClass.class * Eclipse has an active runtime with auto-publish enabled, so events fire off due to the .class change. * The runtime driver processes the resource change event and if it uses the WST PublishUtil class for doing the work it creates an empty temporary file in your workspace area as .metadata/.plugins/org.eclipse.wst.server.core/tmp12345.tmp * Then a file copy is performed from project area file bin/domain/MyClass.class into workspace area file .metadata/.plugins/org.eclipse.wst.server.core/tmp12345.tmp * Then the tmp12345.tmp file is closed, and the modification stamp fixed up (to whatever you want it to be) * Then the file tmp12345.tmp is renamed to another location still within the workspace area but also in the deployment area of the runtime (operating from within the workspace) lets call this path .metadata/.plugins/org.eclipse.wst.server.core/tmp0/webapps/MyProject/WEB-INF/classes/domain/MyClass.class As you can see according to my rules there is nothing wrong with this, a file copy was performed between project build area and workspace runtime instance deployment area and the only rename that occured stayed inside the same area (that being the workspace area). Now the problem occurs when you use an external runtime area and that external directory is not on the same filesystem as the workspace area. This is because if you use PublishUtil from WTP it will still perform the file copy into the workspace tmp12345.tmp file. So my suggestion is to allow the temporary directory where that file copy is performed to be a configurable thing, this way JBossTools-AS can still use PublishUtil class and can instruct it to use a directory like /opt/jboss-4.2.1.GA/server/default/tmp/jbosstools-as/ this making the temporary path ./opt/jboss-4.2.1.GA/server/default/tmp/jbosstools-as/tmp12345.tmp in the above hypothetical situation. When this happens maybe tone down the 64Kb static buffer from PublishUtil to something >= 512 and <= 8192 there are plenty of white papers detailing write performance va write size. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094888#4094888 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094888 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
