[jboss-user] [Installation, Configuration & DEPLOYMENT] - Re: jboss-ds_1_5.dtd Validation problems
This issue got fixed by breaking the "http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142028#4142028 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142028 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: JBoss Tools AS 1.0.0.GA update for JBoss 5 AS ?
Ah yes the first time I wrong the last reply I explained what I did not install. I have Eclipse 3.3.2 + WTP 2.0.2 + JBoss Tools 2.0.0 GA I installed the nightly: JBossAS-Tools-200803280018-nightly.zip I then manually removed the features and plugins of the 2.0.0.GA release of JBossAS-Tools View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141879#4141879 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141879 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: JBoss Tools AS 1.0.0.GA update for JBoss 5 AS ?
I wrote you out a nice reply to this, first time around and this darn bulletin board and its 30 second times out with a redirect back to the jboss homepage ed it up. Here is my 2nd attempt at reply. | !ENTRY org.eclipse.osgi 4 0 2008-04-06 10:26:47.479 | !MESSAGE An error occurred while automatically activating bundle org.jboss.ide.eclipse.as.core (1086). | !STACK 0 | org.osgi.framework.BundleException: Exception in org.jboss.ide.eclipse.as.core.JBossServerCorePlugin.start() of bundle org.jboss.ide.eclipse.as.core. | at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) | at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) | at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) | at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) | at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) | SNIP | at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:1210) | at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195) | at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297) | Caused by: java.lang.NoClassDefFoundError: org/jboss/ide/eclipse/archives/core/model/IArchiveBuildListener | at java.lang.ClassLoader.defineClass1(Native Method) | at java.lang.ClassLoader.defineClass(ClassLoader.java:620) | at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:161) | .SNIP | at org.jboss.ide.eclipse.as.core.JBossServerCorePlugin.start(JBossServerCorePlugin.java:76) | at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) | at java.security.AccessController.doPrivileged(Native Method) | at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) | ... 52 more | Caused by: java.lang.ClassNotFoundException: org.jboss.ide.eclipse.archives.core.model.IArchiveBuildListener | at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:434) | at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) | at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) | at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) | at java.lang.ClassLoader.loadClass(ClassLoader.java:251) | at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) | ... 71 more | Root exception: | java.lang.NoClassDefFoundError: org/jboss/ide/eclipse/archives/core/model/IArchiveBuildListener | at java.lang.ClassLoader.defineClass1(Native Method) | at java.lang.ClassLoader.defineClass(ClassLoader.java:620) | at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:161) | SNIP | at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:1210) | at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195) | at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297) | Caused by: java.lang.ClassNotFoundException: org.jboss.ide.eclipse.archives.core.model.IArchiveBuildListener | at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:434) | at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) | at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) | at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) | at java.lang.ClassLoader.loadClass(ClassLoader.java:251) | at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) | ... 71 more | | !ENTRY org.eclipse.osgi 4 0 2008-04-06 10:26:47.584 | !MESSAGE An unexpected runtime error has occurred. | !STACK 0 | java.lang.NoClassDefFoundError: org/jboss/ide/eclipse/as/core/server/IJBossServerRuntime | at org.jboss.ide.eclipse.as.classpath.core.runtime.ClientAllRuntimeClasspathProvider.resolveClasspathContainer(ClientAllRuntimeClasspathProvider.java:57) | at org.jboss.ide.eclipse.as.classpath.core.runtime.ProjectRuntimeClasspathProvider$RuntimeClasspathContainer.getClasspathEntries(ProjectRuntimeClasspathProvider.java:123) | at org.eclipse.jdt.internal.core.JavaModelManager.containerPu
[jboss-user] [Installation, Configuration & DEPLOYMENT] - jboss-ds_1_5.dtd Validation problems
First of all the URL: http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd does not return the correct document. Second JBoss 5.0.0 Beta 4 DTD resolver for jboss-jca.jar does not seen to be able to locate the local copy of jboss-ds_1_5.dtd . Third if I extract the jboss-ds_1_5.dtd from jboss-jca.jar and put it up on my own website and edit my deploy/foobar-ds.xml to point to my URL it downloads the copy of my website. But that verbatim copy also has problems: Caused by: org.xml.sax.SAXParseException: A ')' is required in the declaration of element type "local-tx-datasource". I presume it is talking about this section, but it all looks good to me: | | | So my real question is how do you turn off the XML validation ? Is there something wrong with my setup ? Surely at least one unit test must have failed before JBoss 5.0.0 Beta4 shipped ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4141875#4141875 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4141875 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: JBoss Tools AS 1.0.0.GA update for JBoss 5 AS ?
"[EMAIL PROTECTED]" wrote : anonymous wrote : I agree with the issue on the other error being due to not using the rest of the nightly build, I did not download and take apart the nightly build to see why it did not gel. Also why does Content Assist require access to IJBossRuntime (when I've not runtimes setup) and also why does Type Hierachy fail to work at all when IJBossRuntime class is apparently missing! So what! | | | You need to explain that to me a bit better ;) | | What kind of content assist is failing ? All kinds, in all contexts I tried, on all artifacts I tried. Simply unzip JBossTools-AS-*-nightly over your GA installation and bootup and try to do some Java work. I really would not be so concerned about it, I'm pretty sure the issue is not with JBoss Tools but the way in which Eclipse hunts/looks/finds things. anonymous wrote : anonymous wrote : < rant > Gee it would be really good when you booted eclipse and it detected a change in plugins if it diagnosed problems an tell you which things were new and which things have become disconnected/disabled < / rant > | | start eclipse with -debug and you get the disconnected/disabled info in the Error Log view. | G-r-e-a-t A-d-v-i-c-e T-h-a-n-k Y-o-u! < sarcasm >Hey with that content assist problem (if you really wanna knock yourself out on that bug), try attaching GDB to the process and looking a look at the disassemble view.< /sarcasm > G-rr-eee--t-! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139730#4139730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139730 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: JBoss Tools AS 1.0.0.GA update for JBoss 5 AS ?
"[EMAIL PROTECTED]" wrote : Dlmiles you are more than welcome to point me to how I could fix the versioning issuewithout messing up plugin and feature manifest/descriptors ;) | | GA in the version string is how we have always done it. | | btw. your other error is probably caused by other weird mixing of nightly builds ...I recommend you use a clean eclipse install and use link files to make sure you only point to a consistent set of plugins. | | If the problem still persist then ping us again. I remember now there was a problem with Hibernate's Eclipse plugin at one point in the past. Well first you have to choose if a user can be expected to do what I tried. That is use the entire GA suite but also install the nightly for just the AS. You may consider this to be unsupported and incorrect use, as each release stream might be considered a different domain to each other (nightly, beta, GA). I didn't want to install the entire nightly suite as I didn't want to introduce known bugs. If you decide that it should be possible to do what I tried (all be it, the user really is on their own, just like they are on their own when they install any or all nightly builds anyway). There is no major problem with the descriptors this time as many of the version constraint simply are not used and those that are seem to be setting the lower bound only. You'll hear no gripes from this direction on that policy it sounds good to me. The issue is simply with the release naming strategy of the GA builds. The letter "G" comes after the number "2". The version comparison is pretty well set in stone for how the eclipse platform works. So if you want it to work then my best/easiest offer is to start using "1.0.0.MMDDHHMM-GA" format for GA releases, and "1.0.0.MMDDHHMM-Beta99" for Beta releases, etc.. you can do what the hell you like after the date part. Bear in mind that you will need to go to version "1.0.1.MMDDHHMM-GA" for the next GA (i.e. at least a patch level bump) from that point on you should find nightly components will at least mix/run with GA components. I agree with the issue on the other error being due to not using the rest of the nightly build, I did not download and take apart the nightly build to see why it did not gel. Also why does Content Assist require access to IJBossRuntime (when I've not runtimes setup) and also why does Type Hierachy fail to work at all when IJBossRuntime class is apparently missing! So what! < rant > Gee it would be really good when you booted eclipse and it detected a change in plugins if it diagnosed problems an tell you which things were new and which things have become disconnected/disabled < / rant > I look forward to the next GA release so that JBoss 5 can be used. I'm sure when the AS is finally released that rolling a new release of JBossTool-AS will get done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139666#4139666 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139666 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: JBoss Tools AS 1.0.0.GA update for JBoss 5 AS ?
"dlmiles" wrote : But the JBoss 5 adaptor is now listed but I am now able to advance past But the JBoss 5 adaptor is now listed but I am NOT able to advance past. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139545#4139545 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139545 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: JBoss Tools AS 1.0.0.GA update for JBoss 5 AS ?
It was necessary to: rm -rf ./features/org.jboss.ide.eclipse.as.feature_1.0.0.GA \ | ./plugins/org.jboss.ide.eclipse.as.classpath.ui_1.0.0.GA.jar \ | ./plugins/org.jboss.ide.eclipse.as.ui_1.0.0.GA \ | ./plugins/org.jboss.ide.eclipse.as.ui.mbeans_1.0.0.GA.jar \ | ./plugins/org.jboss.ide.eclipse.as.classpath.core_1.0.0.GA.jar \ | ./plugins/org.jboss.ide.eclipse.as.core_1.0.0.GA Arggghh! Not again another case of Eclipse plugins getting the concepts of versioning wrong, by putting "GA" in the version="1.0.0.GA" string. Technically the nightly build is a later version than the GA build, it could have been far more correct to use "1.0.0.MMDDHHMM-GA" One thing the Eclipse versioning system does not do is make a distinction between alpha, beta, gamma, release, etc... domains. Then is might be possible to switch off all non-release quality plugins and/or understand that multiple online update sites maybe available. I now also get an error: An internal error occurred during: "Initializing Java Tooling". | org/jboss/ide/eclipse/as/core/server/IJBossServerRuntime On startup, but I can clearly see it inside: # jar -tvf ./plugins/org.jboss.ide.eclipse.as.core_1.0.0.200803280018-nightly/jbossascore.jar | grep JBoss |568 Fri Mar 28 00:44:48 GMT 2008 org/jboss/ide/eclipse/as/core/server/IJBossServerConstants.class |657 Fri Mar 28 00:44:48 GMT 2008 org/jboss/ide/eclipse/as/core/server/IJBossServerPublisher.class |729 Fri Mar 28 00:44:48 GMT 2008 org/jboss/ide/eclipse/as/core/server/IJBossServerRuntime.class But the JBoss 5 adaptor is now listed but I am now able to advance past the selection of the JBoss 5 driver screen, the next button does nothing, the installed runtimes does not light up, I am not able go to workspace properties and create a new runtime of any version (i.e. neither 4.2 or 5 work). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139544#4139544 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139544 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: JBoss Tools AS 1.0.0.GA update for JBoss 5 AS ?
Where are they available from ? I just installed JBossAS-Tools-200803280018-nightly.zip over the top of the last GA release but there is no option to add a JBoss 5 server (except for the one provided by WTP jst.server). I downloaded from http://download.jboss.org/jbosstools/builds/nightly/200803280018-nightly/index.html View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139541#4139541 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139541 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - JBoss Tools AS 1.0.0.GA update for JBoss 5 AS ?
Will there be an update soon to "JBossTools-AS" to include a JBoss 5 deployment adapter from the JBoss Server View ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135215#4135215 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135215 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss/Spring Integration] - Re: JBOSS5 + Spring Deployer version confusion
See also http://jira.jboss.org/jira/browse/JBMETA-5 (which I believe to be the correct channel for updates to jboss-metadata.jar). The XSD validation is picking up the information contained in that JAR. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133474#4133474 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133474 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss/Spring Integration] - Re: JBOSS5 + Spring Deployer version confusion
"alesj" wrote : "dlmiles" wrote : | | Surely there is some other qualifying requirement too. For example the *.deployer file name as well as requiring a META-INF/spring-deployers-beans.xml with outer element ? | | | The file has to be in metadata path, recognized by StructureDeployers. | | I don't know what you mean by *.deployers file name and requiring spring-deployers-beans.xml. | | To require exact outer element, it means it would always have to parse the file, to see what is the first element. | I think the name + suffix are good enough to distinct deployment types. | And with the new aspectized deployers, it's easy to swap out the behavior / add additional constraints. | The point I was getting at, is that no deployer should mindlessly attempt to deploy all files it finds at any nesting depth ending in *-beans.xml. This is mindless madness. But I would be happy for it to have a look at all files and then attempt to parse the file as a JBoss specific deployment descriptor. Now during this process it should immediately see that my file has an XML Schema that belongs to Spring Framework. Upon seeing this the deployer should stop considering that file as a JBoss deployment descriptor and no exception should be thrown. This is the point of having XSDs to ensure an application that is not meant to process some data, does not attempt to process it! The JBoss deployer does not own all the files ending in *-beans.xml that the JBoss VFS can find, it only own those files that also match the DTD/XSD schemes that JBoss understands. Of course it has to parse the file, its bl**dy well doing that now is not it! The error I reported is due to a deployment failure because the contents of the XML appeared to be garbage to the MBean deployer when it attempted deployment. Renaming my file in my WAR from /WEB-INF/spring-beans.xml to /WEB-INF/spring-context.xml did the trick. "dlmiles" wrote : I'm pretty sure this has been fixed in the Servlet web.xml DTD/XSD for a few years now, don't you just love validating parsers. Yes the plus character "+" is valid in a MIME type. I have researched this issue and Tomcat 5.5.x has an updated web-app_2_4.xsd in servlet-api.jar but Tomcat 6.0.14 (the version I checked and the version shipped with JBoss AS 5.0.x) has not been updated. The Bugzilla ticket is at https://issues.apache.org/bugzilla/show_bug.cgi?id=44517 "web-app_2_4.xsd not up-to-date in TC6 servlet-api.jar" For now I shall manually fix servlet-api.jar!javax/servlet/resources/web-app_2_4.xsd in my JBoss installation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133473#4133473 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133473 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss/Spring Integration] - Re: JBOSS5 + Spring Deployer version confusion
Thank you for your replies again.
Picks up ? Ah I see the error is from the deployer trying to deploy something
as a JBoss service which is actually contained inside my EAR which has a WAR
and in my /WEB-INF/spring.beans.xml. I'm surprised it could find it, none of
my containment files are exploded.
Surely there is some other qualifying requirement too. For example the
*.deployer file name as well as requiring a META-INF/spring-deployers-beans.xml
with outer element ?
I'm thinking that just having the name should never be enough but being the
correct name and having a well formed data inside qualifies it for being picked
up and special treatment. Anything not matching all of the requirements should
elicit a warning and then be put back down (and ignored for further pickups
until its timestamp changes again). The warning would be along the lines of
foobar-bean.xml file does not contain outer element, ignoring file and
returning.
Also if there is a clearly DTD or XSD described in the *-beans.xml for which
the deployer does not understand then no warning should be emitted for INFO log
level. But possible to see the attempted pickup at DEBUG level.
Now the next thing in the saga (not really spring related) :
vfsfile:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/Service.ear ->
org.xml.sax.SAXException: cvc-pattern-valid: Value 'application/xhtml+xml' is
not facet-valid with respect to pattern '
| [\p{L}\-\p{Nd}]+/[\p{L}\-\p{Nd}\.]+' for type 'null'. @
*unknown*[164,47][/core]
|
| I'm pretty sure this has been fixed in the Servlet web.xml DTD/XSD for a
few years now, don't you just love validating parsers. Yes the plus character
"+" is valid in a MIME type.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133467#4133467
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133467
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss/Spring Integration] - Re: JBOSS5 + Spring Deployer version confusion
"dlmiles" wrote : Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to parse schema for nsURI=, baseURI=null, schemaLocation=http://www.springframework.org/dtd/spring-beans.dtd I converted all my spring-beans.dtd to XSD (both in the web-app itself and all its included JARs from WEB-INF/lib, what a pain!). My guess on the problem here is that the XML parser is configured by JBoss (as it owns the XML parser and its configuration and supplies it to the JBoss Spring Deployer / Spring Framework). So I am thinking that either the JBoss Spring Deployer should supply a DTD resolver to the JBoss XML Parser that can locate the DTD from within the spring-beans.jar when necessary or Spring Framework is making presumptions about how the XML parser is already configured before it uses it. Anyway now moving onto my next problem. Are all the schemes that spring usually has setup (when running as a web-app in plain Tomcat; not Tomcat under JBoss), are they enabled and functional with respect to JBoss ? In particular the scheme handler for "classpath:" I have a: | | classpath:config/application.properties | | But I'm getting the error: DEBUG [org.jboss.deployers.vfs.deployer.kernel.BeanDeployer] Parsed file: [EMAIL PROTECTED]/Foobar.war/WEB-INF/spring-beans.xml context=file:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/ real=jar:file:/data/opt/jboss-5.0.0.Beta4/server/default/tmp/javatmp/nestedjar19733.tmp!/WEB-INF/spring-beans.xml] to: classpath:/config/application.properties | | DEBUG [org.jboss.deployers.vfs.deployer.kernel.BeanDeployer] Error during deploy: vfsfile:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/Service.ear/Foobar.war | org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/data/opt/jboss-5.0.0.Beta4/server/default/deploy/Service.ear/Foobar.war | at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) | | SNIP | | Caused by: java.lang.ClassCastException | at java.lang.Class.cast(Class.java:2951) | at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:136) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133450#4133450 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133450 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss/Spring Integration] - Re: JBOSS5 + Spring Deployer version confusion
That fragment for jboss-log4j.xml was mean to come out like: | | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133399#4133399 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133399 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss/Spring Integration] - Re: JBOSS5 + Spring Deployer version confusion
Thank for your prompt reply. I was able to turn on logging to see SpringParserDeployer and ApplicationContextDeployer being picked up by editing */conf/jboss-log4j.xml and adding: Also for interest with those reading this thread (as of this time) Spring 2.0 is shipped with JBoss Spring Deployer 3.0. This saves you from downloading every version of Spring framework and comparing JARs until you find a match. I disagree you are not modifying the file by changing the filename by appending the version number like spring-core-2.0.8.jar but would support you stance if I was asking for the content to be modified (which I am not). I can also see that the MANIFEST of jboss-spring.deployer itself does not include its own version number and would also like to see jboss-spring.jar from inside the *.deployer file renamed to jboss-spring-3.0.jar (as well as version in the manifest). Both would be ideal and would save you documenting a README file about which version you built with this week. My next problem is that one or more Spring bean descriptors does not use XSD/Namespaces but DTD, is that allowed ? Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to parse schema for nsURI=, baseURI=null, schemaLocation=http://www.springframework.org/dtd/spring-beans.dtd Now my remaining concern: I have a WAR in my EAR which currently has spring*.jar's inside (/WEB-INF/lib/*.jar) what is the correct way the package those ? If the JBoss deployer version (of Spring Framework) and the WAR version (of Spring Framework) were different, would there ever be a problem, I am thinking that the WAR container encapsulaltion will still work fine, since I would need to go to JNDI to obtain access to an ApplicationContext for any components deployed via JBoss Spring Deployer. Is my understanding correct on this ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133398#4133398 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133398 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss/Spring Integration] - JBOSS5 + Spring Deployer version confusion
I see there is: Spring Deployer 2.1 (in 2.5/2.5.x and 2.0.8 forms) this is a JAR and contains no implementation of Spring and no JBOSS5 style META-INF/spring-deployers-beans.xml. I am correct in thinking the above version is for JBoss AS 4.2.x and older ? But should not be used wit JBoss AS 5 ? I see there is: Spring Deployer 3.0 (which includes a jboss-spring.deployer JAR file, which appears to be in JBOSS5 deployers format, it does not include an implementation of Spring that appears to be older than spring 2.0.7 from filesizes and timestamps). When this file is dropped into the JBoss5 deployers directory I see no log entry indicating startup of the deployer. Should something appear in the JBossAS console log ? I am correct in thinking this should be used with JBoss AS 5 and newer ? Now if I wanted to upgrade to 2.0.7 or 2.0.8 is a recompile necessary or can I replace the spring-*.jar files inside the jboss-spring.deployer file ? Could I also suggest that all dependent JARs what are bundled please use the file name that includes the version of said file like "spring-core-2.0.99.jar" not just the plain "spring-core.jar" so its really clear to audit. This could also extend to the deployer archive itself, jboss-spring-3.0.deployer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133349#4133349 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133349 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
"[EMAIL PROTECTED]" wrote : Ok - we'll look into reproducing fixing this. | | With respect to the bugids did you report those about buffer size not being good enough etc. ? | | Would be good to have the bugids ? | | And yes, the adapter needs to do exploded deployment to trigger this error. Short: I have never lodged bugids about either buffer size or threading issues, I never cared for them enough, more concerned with creating bugids for things that actually affect me rather than a thorny code review. Long: I would guess a windows developer mistakenly thought that using a large buffer 64kb will mean that file writes will handle 64Kb atomically, since most files being published are < 64Kb and this skips over most problems of the runtime being a part built file, NO, NO, NO, NO, NO!. I can only guess this is the illogical reason for this large size. I use the term "windows developer" in the derogatory sense, I hope I offend, ROFL :) The threading issue I commented in another comment to a different bugid, knowing the maintainer for that file may read it. For all I know all server publish actions are serialized and since server drivers are the only things expected to use PublishUtil class there maybe no real problem here, even if I think I see one. It would also be very rare occurrence needing concurrent usage of PublishUtil to trigger, which presumes the user has 2 active runtimes at once, all these factors somewhat reduce its importance to "can't be bothered to write a bug entry for it" status. On the subject of size; I care more that the buffer is shared by all users (is 'static') than about the fact its 64kb, but if you start instancing that class then making it 1Kb should get you within 97% performance, and 4Kb within 99% performance of 64Kb (if you ever through there was a performance issue in the first place) or just allocate a byte[] on demand. Those white papers indicate you get diminishing returns for performance. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095216#4095216 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095216 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
"[EMAIL PROTECTED]" wrote : Ok - my df shows me this: | | so I don't think this could be tested easily on my setup; well I guess I could mount a usb disk and deploy to that ;) | | Have you reported these issues against bugs.eclipse.org ? If not I suggest you to do so and let me know about the bugid and I'll add whatever we do to fix this to that bug. If you don't want to use USB, dig out my post dated "Posted: Tue Oct 9, 2007 01:43 AM" and execute the commands to create yourself a 160Mb loopback file system. This is where Linux mounts a file as a fileing system. The file can exist on your "/" file system as /tmp/bigfile.ext2 Yes I reported the issues for the Tomcat driver with it too did not consider the different file system problems. This was over a year ago and these things were mostly fixed during WTP 0.7/1.0 time frame. But I'm not sure there is a bug with the Eclipse WTP provided JBoss driver, since it publishes to the "tmp0/" directory in exploded format (without using the .ear directory extension), once that pass is complete it then creates an EAR file in the JBoss runtime deployment directory (out of the contents it just put into the "tmp0/" directory). So in effect converting from exploded format to single file EAR format implicitly means Eclipse ends up doing a file copy. I am completely guessing this is what it does from my observations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095180#4095180 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095180 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
"[EMAIL PROTECTED]" wrote : I just can't reproduce this error and thus I'm asking you if | | a) this occurs with other deployers too | | b) did you see leftover artifacts when using our jboss deployer | | If a and b then this is most likely limited only to possible issues in jstpublisher, if a and not b or not and b then it is some issue specific to our tooling. a) I can't comment on 'a' since I don't have any other deployers setup, just Tomcat and JBoss. As I understand the limitations with Java/JVM and Unix system semantics I'm happy to claim that all users of WST PublishUtil are affected while the "File tempDir" member has a hardwired value. It's important to phrase the question 'b' correctly "this occurs with other deployers that deploy to runtimes outside of the workspace filesystem that also use PublishUtil class provided by WST in WTP to place the files into the deployment directory". Maybe you can pick a deployer and container you'd like to me to spare a minute to test it with ? b) Yes I do. Here are the left over files (from $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/ to my example EAREclipseManager.ear project from deploying a moment ago: tmp40855.xml tmp40856.MF tmp40857.xml tmp40858.class tmp40859.class tmp40860.class tmp40861.class The modification to the JBoss runtime deploy directory has all the directories created that I'd expect to see for the project, but the 7 missing files are the MANIFEST.MF, the ejb-jar.xml, the application.xml and 4 x Implementation .class files. Examining the contents of those 7 tmpX. files clearly indicate they are those files, left over from failed renameTo() calls. I'd like to help you observe the issue, this would be best on a linux system (as that is what I use day-to-day). Please confirm your file system layout from 'df', the absolute location of your workspace, the absolute location of your project, the absolute location of your jboss runtime. I can then confirm if I believe your configuration should be able to observe the problem and provide steps. anonymous wrote : And we can't perform that change since it won't be ready in a WTP release in time; so we probably need to fork PublishUtil to make it work. There is always the option of listing the (cross filesystem boundary) as a known issue for the CR1 release. Since it is not that difficult to work around for a developer to ensure his runtime is on the same file system as his workspace. Open an API request ASAP and creating a backwards compatible implementation of the static PublishUtil and a new instancable delegate. But... I do think the lack of UI feedback over publish failure is a MUST FIX item for any major release. When the renameTo fails the user must know (no silent failures). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095061#4095061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095061 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
"[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 herebut 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
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
"[EMAIL PROTECTED]" wrote : I stepped through the code of jstpublisher andi don't see any temp file copying being performed when we use our adapter...I do realize that tomcat and jboss adapter does this of different reasons (tomcat - has it as a "deploy" location and jboss wtp as a tmp storage before zipping it up) | | I'm not saying we don't have issues across disk boundaries; i'm just saying i'm not seeing any temporary files being created... My comment earlier was that I guess you delegate the task of the actual file copy to PublishUtil and as it stands this API provided by WTP is only good if you intend to use the ".../tmp1/" publishing area (due to this cross file system concern). This is why I think you need to open an API change request with WTP (or at least have them knock you back and fork your own implementation of PublishUtil). I can see any reason why you can't have the API improved as it should be possible to maintain 100% backward compatibility. The copy of PublishUtil I have from 1.5 still has the bug that is uses a static variable for the file copy buffer and this class is shared by many drivers, and as far as I know having two runtimes active at the same time is allowed and updates maybe done concurrently. So instancing this class with a private 'byte[] buffer' and a configurable 'File tempDir' makes sense to me. Anyway to spot the temp file usage try something like this: Set a breakpoint in this class org.eclipse.jst.server.core.PublishUtil for all methods, or rather org.eclipse.wst.server.core.PublishUtil (since it appears to have moved between 1.5.x and 2.0). I only have WTP 1.5 tree checked out, I don't know if there is a viewcvs HTTP resource to cite more information so I can't see what the current WTP 2.0 PublishUtil looks like. Set a breakpoint for java.io.File#createTempFile(String, File), modify a .jave file and save, do a publish with th JbossTools-AS driver. If you open the source to the PublishUtil class and look for "temp". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094825#4094825 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094825 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
"[EMAIL PROTECTED]" wrote : Thanks for all your help in this. I really wish I could have dedicated more to it before you did, but hey, thats hte benefit of community right? | | >> What does this idiom "copied = copied &&" do ? | | That's my attempt to make sure *all* files were copied correctly. If any single file is not copied, the end value of copied would be false. Yes sure on the community comment. I still don't understand the "copied = copied &&" I can't see how it works (even if you presume an optimizing JVM does not remove the operation due to redundancy). Its a single "=" character, if it were a compare operator then that would fail fast (as oppose to try to copy everything with best effort) even though copied is not set to anything other than 'true' AFAIS. "[EMAIL PROTECTED]" wrote : I never seen anything in that tmp file location you mention - it just contains a profile.dat file which I think just represents the last list of resources that have been copied ? Can you be more specific? Are you windows or linux ? Have you ever create a Tomcat runtime and WAR/DWP deployed to it ? Have you even created JBoss runtime using WTP driver and deployed to it ? If no and no then I wouldn't expect to see much in the directory if you've never had a publish failure. What is the specific path on your computer you are looking at ? Can you confirm the absolute path to your JBoss runtime, I have not verified if the problem I see is re-creatable on windows by having JBoss runtime on a different drive letter. I'm not sure if windows has rename magic (which turns out to be a file copy) if you rename a file across drive letters. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094712#4094712 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094712 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
It looks like you are leaving the work of the actual copy to WTP's PublishUtil
class.
My understand of how this works inside WTP is that it does a file copy of each
file to the directory
$HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp12345.class
and then does a rename to the final deployment location (which WTP is expecting
to be in a directory like
$HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp1/
If you check your directory
$HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/ both before and
after your a publish with JBossTools-AS where your runtime is on another file
system you should see left over files appear and the number of files in the
directory grow. It does not seem WTP deletes the old temporary after the
renameTo() failed.
This works great for Tomcat and other such containers that can treat the "tmp1"
directory above as a deployment directory but not do useful if the runtime it
somewhere else.
Since all the built in WTP runtime tools I have seen use the "tmp1/" directory
in the workspace area as the deployment area you can't expect these tools to
work for deployment outside of the workspace area.
My suggestion would be for JBoss to open up an API request with the server
tooling to allow the PublishUtil tool to be instanced and configured an exact
path to be used as the temporary location to copy to.
File tmpDir = new File("/opt/jboss-4.2.1.GA/server/default/tmp/jbosside-as");
| if(!tmpDir.getParent().exist() == false)
| throw new RuntimeException("Directory " +
tmpDir.getParent().getAbsolutePath() + " does not exist");
| tmpDir.mkdirs();
| PublishUtil publishUtilInstance = new PublishUtil(tmpDir);
|
| // Then in your code instead of using the static methods use the instanced
ones
| publishUtilInstance.callSomeMethod(someArgs);
|
So it looks like to me you need a way to pass down a temporary path that WTP
standard methods can use as the temporary directory to perform the initial copy
from the "project build area". This is runtime specific. Its also concerning
that the rename must have failed and that no error is indicated in the UI so
there is another area to look at in that.
What does this idiom "copied = copied &&" do ?
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosstools/trunk/as/plugins/org.jboss.ide.eclipse.as.core/jbosscore/org/jboss/ide/eclipse/as/core/util/FileUtil.java?view=log
|
| #fileSafeCopy(File src, File dest, IFileUtilListener listener) {
| copied = copied && fileSafeCopy(subFiles,
newDest, listener);
| }
|
| // I would think that propagation of an error would but more correct here :
|
| if(fileSafeCopy(subFiles, newDest, listener) == false) {
| copied = false;
| }
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093910#4093910
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093910
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
http://jira.jboss.org/jira/browse/JBIDE-1047 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092840#4092840 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092840 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
"[EMAIL PROTECTED]" wrote : i'm still unable to reproduce the problems you mentioned at the beginning of the thread. Thanks for the feedback that it works with your setups (Max/Rob), so I have investigated some more. I have confirmed I am running beta4 (just to be sure). My conclusion is that there is indeed a problem when the JBoss runtime is not on the same file system as the "project build area". As I setup another runtime in my home directory and that published with the JBossTools-AS fine. I then moved this same runtime instance to another file system, and manually cleaned the servers/default/deploy/MyEAR.ear/ directory from it and proceeded to setup a new runtime in this location too (I could not edit the runtime home on the existing instance it would not let me). When I published I got the directory tree created and the MyJAR.jar (a Utility JAR for the EAR classpath) but none of the other files were created. So I would guess that you too are not doing a file copy but a rename, just to be clear its only the final step of making the file visible to the runtime that interests me and indeed is what this thread concerns, you can use whatever method/algorithm you like in preparation for that final setup. I shall find or open a new JIRA now, I don't think its difficult to recreate, type 'df' from linux to understand your filesystem layout and then use 'df /home/myuser/workspace' and 'df /somewhere/jboss-4.2.1.GA' to verify the two locations are on different file system. If you don't have a big enough alternative filesystem with your linux install, then create a loopback one: dd if=/dev/zero of=/tmp/bigfile.ext2 bs=1k count=163840 | /sbin/mke2fs /tmp/bigfile.ext2 | # Say Yes to proceed | mkdir /mnt/loop | su | # Enter root password | /bin/mount -o loop -t ext2 /tmp/bigfile.ext2 /mnt/loop | df /mnt/loop | cd /mnt/loop | unzip jboss-4.2.1.GA.zip | | # To tear it down as root | /bin/umount /mnt/loop | rm /tmp/bigfile.ext2 | I can't speak for Windows, but I would have expected using different drive letters would have the same effect. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092835#4092835 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092835 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
"[EMAIL PROTECTED]" wrote : No - we don't use renameTo(), we use copy. What we do in case of updates I'll need to check in code - or maybe even get rob to chime in. Do you copy in situation ? This is what tomcat driver used to do in WTP0.7 thru WTP1.0 or so. Copy in situation means to me you take the existing file, truncate it, then write blocks of data repeatably to it, then close the file. The file instance is the same after the copy as it was before the copy. This can cause the JVM to crash when applied to JARs which change. I would get between 5 JVM crashes a day on Linux when developing for Tomcat, this is always because I had a contributing J2EE Utility project which I was also developing in parallel to the web-app. The problem is that the JVM holds an open descriptor to the file and possibly has a mmap() in place for the contents and continues to access it, expecting the old contents to be there. You can't change contents from under the JVM, you need to make a new file instance and replace (on unix, on windows file locking becomes an issue and was the reason for the broken methodology in the TC driver in the first place) anonymous wrote : And I've never bumped into these issues and I run both on Linux and Windows...maybe my machine is just too fast ... True the window of time problem can be made visible with a slower machine. Getting a faster machine can cover up the problem but none the less there is a design issue. anonymous wrote : The descriptor is not updated before the user actually updates it, but I can see how it might be relevant when doing a full update. Okay another beef I have here is that tools like XDoclet which modify descriptor don't do a replace-if-modified check after they build the new descriptor file. This means the timestamps on descriptors can keep incrementing when the contents were computed to be the same as the previous version. So there are cases where the user may not have actually modified a descriptor but the system did it for them (or rather the system modified a dependency which causes a rebuild of the descriptor but it turns out no change to the descriptor resulted).. This is very annoying and non productive to a developer. The tooling uses incremental updates anyway for the large parts everything I'm saying relates to that. anonymous wrote : With respect to the deployer ignoring updates if a certain file is present that is something I always thought about doing but is it really an issue in day-to-day dev ? | | I think you raise some valid issues, I'll point Rob to this thread; but I would also really like to have concrete examples of things actually failing because of these things (your missing files is not one of them as far as i can see - they might be a cause of something else which we definitly needs fixing) Its too soon for me to say if IMHO its a issue in day-to-day, certainly in tomcat the develop-run-test cycle is faster especially in relation to JSPs. So it did make a difference there. This is early days for me using JBossTools-AS the large part of this comment is really clarifying the issues I found with TC which has now been fixed in WTP so I'm happy to provide the heads up and make you think in this realm about these matters. But sure I don't have any concrete examples of bad things with JBossTools-AS at this moment because I've not gotten past the basic functionality of deploying an app. :) "[EMAIL PROTECTED] from another post" wrote : Another thought is that a ant build file doing incremental updates would have the exact same issues My thoughts here are I don't care as I always considered such ant tasks broken by design and have done deployment by copying a file to "default/deploy/MyEAR.tmp" and then renaming the file to "default/deploy/MyEAR.ear" to make it visible to the deployer with a trivial script. One problem here is that Windows really doesn't have a transactional file system, it does not allow files that are open by another process to be deleted or renamed (not in Win2000 and Win98SE etc..) the concept was an after thought to the windows API added to WinXP. It does not allow a transactional rename, i.e. because the target of the rename has to be deleted first, and it can only be deleted if no other process has it open, so there is a window of time when another process will see no file exists. Unix on the other hand does have a transactional file system the semantics of which are mandated by POSIX. It does allow a file than is open by another process to be deleted and/or renamed. It does have a rename() call which will replace the existing target atomically. Unix has had very specific semantics for dealing with updating files atomically for many years, take the example of updating /etc/passwd to add a new account, what horrors would result if the /etc/passwd file for just a moment didn't exist, because another process deleted it before doing a re
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
"[EMAIL PROTECTED]" wrote : I haven't had time to reproduce your scenario, but if WTP default adapters does not work with it then something else is missing. | | Check out the prjoects beta4 of jbosstools (announcing later today, but already available for download) generates for Seam EAR ...it is just using normal WTP funcitonallity. | WTP is working (after I cleaned by deploy/ dir manually of the exploded EAR) and WTPs default mechanism is to deploy to a EAR file (not exploded). FYI: I am already using beta4 (as per the thread subject :-) ). anonymous wrote : Yes - apparently default WTP adapter does not check if the project is already deployed (and possibly exploded) | | Yes - that is the most efficient way of deploying/developing so that is what we do by default. All Agreed. anonymous wrote : * Does it matter that my workspace and my JBoss runtime location are on different file system (different drives), since its not possible to rename files between my workspace and the JBoss runtime location. The IDE must perform a file copy. | | anonymous wrote : I don't understand the question. | | | | Renames/Deletes/Creations in your workspace will automatically be reflected on to the deployment location incrementally. | | | | why should that be affected by them being on different drives ? The Java operation that is "java.io.File#renameTo()" does not work across filesystems (or Drive letters I expect with windows). The only way to move a file from one filesystem to another is with a file copy. With Eclipse you can never assume the workspace filesystem, the project filesystem are the same. In the case with server tooling you can also never assume the filesystem your JBoss runtime is located on is the same as either of the above. For example: Workspace => C:\workspace Project => D:\project JBoss Runtime => E:\JBoss-4.2.1.GA\ So this is why its necessary to copy a file from your project build area into a temporary location in the JBoss Runtime first and then move it (via a rename) to the deploy subdir. * Copy file D:\project\bin\domain\MyClass.class to E:\JBoss-4.2.1.GA\server\default\tmp\MyClass.tmp * Fix modification stamp on E:\JBoss-4.2.1.GA\server\default\tmp\MyClass.tmp * Rename E:\JBoss-4.2.1.GA\server\default\tmp\MyClass.tmp to E:\JBoss-4.2.1.GA\server\default\deploy\MyEAR.war\MyEJB.jar\domain\MyClass.class So as you can see if the implementation of server tooling does not follow the strict methods outline above bad things can happen. For example: * If you try to rename directly from workspace/project into jboss runtime tree, then that wont work and _SHOULD_ indicate error from the #renameTo() call, you are checking all the error returns aren't you ? (another issue some people think it Throws an exception, which it can but most run of mill errors are indicated in the boolean return value). * If you try to fix modification stamp after you make the file visible to the runtime (by putting it into deploy/ subtree) then its possible the runtime will see the old timestamp first. * If you try to copy files directly from workspace/project tree directly into the final destination path then its possible to the runtime will see the partially built file and act upon it. This is one reason why modifications to descriptor should always be done last, like WEB-INF/web.xml is always the last update (reorder it if necessary). * If you try to copy files directly into workspace (by way of file truncation followed by file writes) you will get random crashes when you do this with jars on unix, since the active JVM the container is using cached information from the ZIP header or something but you just modified the contents, so its seeks to the wrong place, decodes something and crashes due to seemly corrupt data, yeah sure the JVMs ZIP implementation needs to be more robust but you cause the problem when you changed the file contents. * Any errors on file manipulation must always be shown to the IDE user, ensure you check the return values correctly. * Ideally when an IDE is making modifications to the a container runtime that is live it needs to do this in co-operation with that container. Basically you need to inhibit the deployer from acting now, even if it sees a timestamp change, while the IDE is will modifying, easiest way to do this is to have the IDE create a file like WEB-INF/deploy-ide-update.properties, which its mere existance makes the container busy loop after the moment it detects a change but before it performs a deployment action because of the detected change; until the file is removed by the IDE. Discussion on one this is best left for another time. The original Tomcat server tooling between WTP 0.7 and WTP 1.5.x was making many of these errors. Some of the reasons were due to a windows way of thinking about the world as opposed to a unix one (a transactional one). anonymous wrote : * When the files a
[jboss-user] [JBoss Tools (users)] - Re: WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing corre
Hi Max thanks for the reply. Okay this is what I can tell you about things: I have an "EAR Project" called "EAREclipseManager", this has 2 artifacts added to it. These are 1 x "J2EE Utility project" called "TheLibrary" and 1 x "EJB Project" called "TheEJB". If I do a project properties on the "EAR Project" under "J2EE Dependancies" I has a tick for both of the other two projects set. The EAR Project has the Project Facet "EAR" set to "5.0", Project References also has a tick for both of the other two projects set, Seam Support is disabled (no tick in box), Targetted Runtime is : JBoss AS 4.2. Is is the encapsulating EAR project I am trying to publish. I don't think I need to do anything special with the project settings of the 2 contributing projects do I ? The deployment appears to be attempted in: /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheLibrary.jar | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/META-INF/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/META-INF/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ejb/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ejb/manager/ | /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear/TheEJB.jar/my/foobar/eclipse/ejb/manager/test/ | Hmm... when I run a "clean" function from the server tooling with the WTP provider driver I get an error: [jar] Building jar: $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/EAREclipseManager.ear | [move] Moving 1 file to /opt/jboss-4.2.1.GA/server/default/deploy | | BUILD FAILED | /opt/eclipse/plugins/org.eclipse.jst.server.generic.jboss_1.5.105.v200709061325/buildfiles/jboss323.xml:33: Failed to copy $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2/EAREclipseManager.ear to /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear due to /opt/jboss-4.2.1.GA/server/default/deploy/EAREclipseManager.ear (Is a directory) Is it possible to confirm 2 things: * Which method of deployment does JBossTool-AS use, does it create an exploded EAR ? When it created that exploded EAR does it create a directory with a ".ear" extension in the deploy directory ? Does an exploded EAR need to have a .ear extension so its treated correctly by the correct deployer ? * Does it matter that my workspace and my JBoss runtime location are on different file system (different drives), since its not possible to rename files between my workspace and the JBoss runtime location. The IDE must perform a file copy. * When the files are copied are they copied atomically, i.e. each file is copied into tmp/filename.tmp first, then its last modified time is fixed to whatever it needs to be, then its renamed (i.e. moved) to the deploy/whatever/filename.foo. There are other such things which should take place when updating a working runtime but maybe more on that once I have the basic thing ticking along. Okay I have manually cleaned the JBoss deploy directory of my project and let the WTP JBoss driver do its stuff and it create an .ear file in the correct directory and when JBoss starts it finds both application.xml and my TheEJB.jar implementation. I cleaned things again and tried with the JBossTool-AS driver and it created a directory with .ear extension, the tree is just like I put in the CODE block above, with AREclipseManager.ear/TheLibrary.jar being the only file and the application.xml and the .class files are all missing. So the problem for me appears to be with the JBossTool-AS driver (which is my preferred choice). Would there be any call to allow JBoss to take a command line property to configure a 2nd and alternative deployment directory ? The purpose of this would be to allow for a Tomcat like situation where the workspace area could be used for the deployment, when you just alter the driver to contribute the property to the launch configuration when it sets things up. Okay it would not be 100% compatible with tomcat since the work, tmp, log, etc.. directories would also need to be picked up based on the alternative path too. Just a thought, since it would seem difficult for "clean" to mean clean if the deploy directory was not empty to start with. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092549#4092549 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mod
[jboss-user] [JBoss Tools (users)] - WTP2.0.1, JBossAS-Tools-1.0.0.beta4 not publishing correctly
When I publish an EAR project from my workspace into JBoss 4.2.1 it does not publish correctly. I have tried both the WTP supplied 4.2 driver and the JBossAS-Tools supplied 4.2 driver. My JBoss runtime is at /opt/jboss-4.2.1.GA this directory tree is writable by my userid, also exists is $HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2 which is also being published too as well as. After a successful publish operation (successful from looking at the GUI, but unsuccessful from looking at the JBoss log) the following things happen: The JBoss runtime home (/opt/jboss-4.2.1.GA/data/opt/jboss-4.2.1.GA/server/default/deploy/) ends up with an exploded EAR directory (this is the name of my project with the .ear extension but its a directory not a file), inside this directory is all the other subdirectories that make up the tree, but the only file in there is that of a Utility JAR. There was no META-INF/application.xml and there is no EJB implementation JAR. In the workspace server plugin temporary area for this server instance ($HOME/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp2) I find an EAR file (which internally has my META-INF/application.xml, my Utility JAR and my EJB JAR). It also has a directory (same name as EAR but without the .ear extension) this has all 3 files I'd expect to see in an exploded EAR tree. When looking at the launch configuration for JBoss I can't see where the workspace deployment location is specified in the configuration, so I can only presume that what JBoss sees is only the file copied into the runtime home. Unlike Tomcat which can have a read-only runtime home but a read-write instance tree allowing for the sharing of the container by multiple instances in server tooling. What copies the files during deployment into the JBoss runtime tree ? Is there anyone who is actually using the server tools successfully in this way ? If so what versions of things to you have installed ? I'm using: Eclipse 3.3.1, WTP 2.0.1, JBoss 4.2.1, JBossAS-Tools-1.0.0.beta4 Thanks, Darryl View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092394#4092394 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092394 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
