"max.andersen(a)jboss.com" 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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...