[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
Yah, if you guys could add .rails as a jar extension for the GA, that'd be plenty fine for my needs. Thanks! -Bob View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193732#4193732 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193732 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
bob.mcwhirter wrote : Yah, if you guys could add .rails as a jar extension for the GA, that'd be plenty fine for my needs. This will be by default in AS5 GA: | +value.spring/value | +value.rails/value | +value.esb/value | There is also a jira to track further changes we need to do for the next point release: https://jira.jboss.org/jira/browse/JBAS-6274 But keep you JEP, as this is going to be removed once this is done :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193733#4193733 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193733 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
Let's add all legacy one's we can think of, otherwise users might be in for a surprise. - .beans - .spring - ... ? Adding a TODO - to remove them once this issue is fixed (do we have a JIRA?). View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193691#4193691 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193691 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
bob.mcwhirter wrote : | So, it seems that since things initialized from deployers/ can affect VFS handling, deployDir.getChildren() should wait until deployers/ is fully deployed. | | Possible? Possible yes, unfortunately not in the timeframe of GA. But we could add your .rails extension by default to the deployers.xml and once this is fixed we remove it again, if this would help you ? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193687#4193687 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193687 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
Hi, anonymous wrote : But we could add your .rails extension by default to the deployers.xml | and once this is fixed we remove it again, if this would help you ? Would it also be possible to add the '.esb' extension in that case? Thanks, /Daniel View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193689#4193689 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193689 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
Okay, I gave this morning's nightly build a try, and I'm still seeing a timing issue between my JEP and the deployment scan. But the problem has moved. But first, congrats on making the nightlies boot up much much faster than CR2 even. That's very pleasant. Now my analysis... The HDScanner in deploy/ helps, as it doesn't seem to trip over the .rails archive before it's recognizable as a vfszip. But there's still conf/bootstrap/profile.xml setting up and starting a VFSDeploymentScanner, which has inherited the scanning-deploy-too-soon issue I saw the other day with HDScanner. This non-hotdeploy, boot-time scan grabs myapp.rails with a FileHandler before my deployer has had its JEP triggered. It's still a bootstrap scanner iterating deploy/'s children before deployers/ has been fully install, I think. Having scan() wait at a barrier of some sort until the DEPLOYERS phase is complete would seem a possible solution. Thoughts? -Bob View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193469#4193469 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193469 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
bob.mcwhirter wrote : | It's still a bootstrap scanner iterating deploy/'s children before deployers/ has been fully install, I think. Having scan() wait at a barrier of some sort until the DEPLOYERS phase is complete would seem a possible solution. | So, if I understand this correctly, we have another 1-time-only boot scan. And it's before DEPLOYERS phase? I need to check this, as it's clearly wrong, for obvious reasons - for one this suffix case. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193478#4193478 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193478 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
I may be wrong in that analysis, looking further. I'd assumed conf/ is recursively loaded. bootstrap.xml does not directly reference the bootstrap/profile.xml any more. There's a bootstrap-minimal.xml and bootstrap-norepo.xml that do reference it though. If the VFSDeploymentScanner isn't actually being used (I'll check in my logs in a minute), then I don't know what the problem is. But I'm still seeing the problem. And something is causing deploy/myapp.rails to go through structure recognition before HDScanner does its first run. Structure recognition is coming after my JEP installation. But I'm still ending up with a FileHandler'd archive if myapp.rails is in deploy/ at boot time, but getting a correctly handled vfszip if HDScanner picks it up post-boot. I'll keep digging. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193484#4193484 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193484 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
The hotdeployment scanner initialization has been moved to deploy/hdscanner-jboss-beans.xml, so it cannot be deploying anything before the deployers are initialized. The profile service that is loaded by default now is the conf/bootstrap/profile-repository.xml. It is doing a rebuild of the structure metadata when it loads admin edits, so that must be causing this. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193511#4193511 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193511 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
Scott-- Thanks for the response. Is this something fixable? By GA? Or is there some work-around you can think of? Thanks, -Bob View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193520#4193520 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193520 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
This whole system seems weird to me. Why does the MC not suspend deploying a file until there is a matching deployer for it? That would seem to be more reasonable to me. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193526#4193526 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193526 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
[EMAIL PROTECTED] wrote : | The profile service that is loaded by default now is the conf/bootstrap/profile-repository.xml. It is doing a rebuild of the structure metadata when it loads admin edits, so that must be causing this. It is only rebuilding the structure if you persisted managed object before, as i don't think you are doing that - i guess this is not the case. But to be sure - there should be some debug information in the boot.log like this: (well they are there since today :) | DEBUG [AbstractAttachmentStore] No persisted attachment found for deployment ... | If i do a simple RailsStructure implements JarExtensionProvider, it is deployed before any file in the deploy directory is added to the mainDeployer. | DEBUG [DeployersImpl] (main) Fully Deployed vfsfile:/home/emuckenh/svn/as/jboss-5.0.0.GA/server/default/deployers/rails-jboss-beans.xml | So not really sure yet, why your Structure shows up too late. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193543#4193543 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193543 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
It's not so much my structure shows up too late, but rather the JEP portion shows up too late for something calling getChildren() on the deploy/ directory, it *seems*. It's handing the child to my deployer at the right time, but it appears that the getChildren() against deploy/ is happening before JEP installation, so it doesn't know that myapp.rails should be handled as a JAR instead of as a normal filesystem file. At least that's what I'm thinking is happening. A hot deploy after AS is fully running, the getChildren() is smart enough to delegate to a JARHandler for myapp.rails. Anyhow, I have not been able to figure it out yet. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193545#4193545 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193545 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
bob.mcwhirter wrote : | It's handing the child to my deployer at the right time, but it appears that the getChildren() against deploy/ is happening before JEP installation, so it doesn't know that myapp.rails should be handled as a JAR instead of as a normal filesystem file. | | At least that's what I'm thinking is happening. A hot deploy after AS is fully running, the getChildren() is smart enough to delegate to a JARHandler for myapp.rails. | Ah now i finally understand what you mean :) Yes there is a call of deployDir.getChildren before your JEP is getting deployed. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193554#4193554 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193554 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
emuckenhuber wrote : | Yes there is a call of deployDir.getChildren before your JEP is getting deployed. | Actually this happens before anything else is deployed. We should be able to do that in a different way. I'll see if we can put this still in GA. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193555#4193555 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193555 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
emuckenhuber wrote : | Ah now i finally understand what you mean :) | Yes there is a call of deployDir.getChildren before your JEP is getting deployed. | A-ha! So, it seems that since things initialized from deployers/ can affect VFS handling, deployDir.getChildren() should wait until deployers/ is fully deployed. Possible? Thanks, -Bob View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193556#4193556 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193556 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
anonymous wrote : | If you mark one of your deployers as JarExtensionProvider | My RailsStructure deployer implements JEP. Additionally, I've added setJarExtension( .rails ) on one of my parsing deployers (seems like a weird place for it, honestly), since AbstractParsingDeployerWithOutput implements JEP, too. Both result in the same FileHandler'ing of my oddthesis.rails JAR, instead of the DelegatingHandler/JarHandler. anonymous wrote : | + you put your deployers into deployers directory (the proper way) | Yah, I've been using deployers/ always to deploy the jboss-rails.deployer itself. anonymous wrote : | you should be fine, as deployers are booted before deploy is scanned. | -- different boot phases: BOOTSTRAP, DEPLOYERS, APPLICATIONS Yah, that's what I figured the code told me, but it still seems that boot-scan doesn't enable the .rails in time for the VFSContextFactory bits, even for deploy/ but subsequent scans do. I'm going to keep poking, and I'll update here. Thanks, -Bob View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193264#4193264 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193264 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
bob.mcwhirter wrote : | My RailsStructure deployer implements JEP. Additionally, I've added setJarExtension( .rails ) on one of my parsing deployers (seems like a weird place for it, honestly), | This mostly comes from our legacy usage. e.g. -beans.xml was packed as .beans my SpringDeployer expected .spring + -spring.xml. bob.mcwhirter wrote : | Yah, that's what I figured the code told me, but it still seems that boot-scan doesn't enable the .rails in time for the VFSContextFactory bits, even for deploy/ but subsequent scans do. | Hmmm, could be that getChildren is called to soon on deploy/. I'll check tomorrow (just downloading IDEA 8.0.1 :-) or if you dig up something while poking. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193266#4193266 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193266 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
So, a quick analysis might confirm your suspicions of HDScanner doing the scan() too soon. I may be confused, of course, but here's my amateur analysis... While HDScanner itself is a BOOTSTRAP bean, I assume it gets completely start()'d and running before the DEPLOYER phase. When start()'d, it scan()'s. Conceivably scanning deploy/ for APPLICATION before all deployers have been deployed. Hence getChildren(...) on deploy/ not being enabled to view .rails archives as vfszips. Maybe. :) Looking at my log timestamps, I see... | 16:11:20,978 TRACE [HDScanner] Begin deployment scan | Then a while later (5 seconds), my log indicates the JEP installation from my deployer in the deployers/ directory. | 16:11:25,860 INFO [RailsStructure] getJarExtension()... | I don't know the implementation of the solution, but seems like some barrier on the start()/scan() of HDScanner to hold it until the DEPLOYER phase is completely completed, perhaps. For now, I can just use .jar as an extension. Thanks, -Bob View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193270#4193270 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193270 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
bob.mcwhirter wrote : | While HDScanner itself is a BOOTSTRAP bean, I assume it gets completely start()'d and running before the DEPLOYER phase. | Not any more, it's part of deploy/ now (build trunk). - http://anonsvn.jboss.org/repos/jbossas/trunk/profileservice/src/resources/hdscanner-jboss-beans.xml View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193271#4193271 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193271 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
anonymous wrote : | Not any more, it's part of deploy/ now (build trunk). | Okay, I'm still on CR2 at this point. With the move from conf/profile.xml to deploy/... should cause the ordering to be happier, as I understand it. Thanks for the follow-up. I'll use .jar as an extension with appropriate content introspection to identify my rails deployments for now. I don't want to be dependent on a build from SVN, since I'm hoping other people will use all of this, too. Or I may try to locate some nightly builds. Or wait for GA. Thanks! -Bob View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193272#4193272 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193272 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
Weird, we've added JarExtensionProvider (JEP) for exactly this reason. We usually have parser deployers that implement this interface. e.g. BeanDeployer -- -beans.xml + JEP .beans (old extension) I'll have a look, although I remember adding test for it. btw: no need for install, as JEP is contextually injected via callbacks into JARStructure ;-) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193200#4193200 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193200 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
alesj wrote : | I'll have a look, although I remember adding test for it. - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-vfs/src/test/java/org/jboss/test/deployers/vfs/matchers/test/JarExtensionsTestCase.java View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193201#4193201 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193201 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
Doing some more debugging... It *does* seem to affect the JarUtils.isArchive(...) call successfully, and JARStructure will match my .rails since, as the deployer says... ... ok - its an archive or at least pretending to be. But it's still mapping to a FileHandler instead of a JarHandler | 19:47:57,193 DEBUG [RailsStructure] Determining structure for [EMAIL PROTECTED] context=file:/Users/bob/oddthesis/jboss/jdk1.6/jboss-5.0.0 | .CR2/server/default/deploy/ real=file:/Users/bob/oddthesis/jboss/jdk1.6/jboss-5.0.0.CR2/server/default/deploy/oddthesis.rails] | and | 19:47:57,194 TRACE [JARStructure] ... ok - its an archive or at least pretending to be. | 19:47:57,194 TRACE [JARStructure] Added context [EMAIL PROTECTED] from oddthesis.rails | 19:47:57,194 TRACE [JARStructure] Added classpath entry for oddthesis.rails from [EMAIL PROTECTED] context=file:/Users/bob/oddthesis/jbos | s/jdk1.6/jboss-5.0.0.CR2/server/default/deploy/ real=file:/Users/bob/oddthesis/jboss/jdk1.6/jboss-5.0.0.CR2/server/default/deploy/oddthesis.rails] | The JARStructure happily sets up the ContextInfo etc. The RailsStructure fails though, since I go digging around in root.getChild( config ) to see if it *really* is a rails archive (similar to how JARStructure looks for META-INF/). FileHandler's getChild(...) doesn't do the job. If I remove my oddthesis.rails archive from deploy/, and then add it back, it *is* then recognized as a JAR archive from a VFS point-of-view, and then my RailsStructure matches it from the StructureDeployer point-of-view. | 20:11:06,310 DEBUG [RailsStructure] Determining structure for [EMAIL PROTECTED] context=file:/Users/bob/oddthesis/jboss/jdk1.6/jboss | -5.0.0.CR2/server/default/deploy/ real=file:/Users/bob/oddthesis/jboss/jdk1.6/jboss-5.0.0.CR2/server/default/deploy/oddthesis.rails] | So, to me, it seems like a timing issue. The JarUtils.addJarSuffix(...) happens soon enough for JARStructure to see and use it, but *not* soon enough for the HDScanner/Profile/whatever that initially loads the deploy/ directory and constructs the VirtualFile/VFSContext from its children. Your test is correct, but isn't quite testing the problem I'm seeing, I think. If the deploy/oddthesis.rails archive is present at boot, it's mis-handled. If it's added *after* the system is fully booted, it is correctly handled with a JarHandler. Is there some way to register the jar extension extra-early so that the deploy/ directory scanner has it when it's first scanned at boot time? Thanks! -Bob View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193206#4193206 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193206 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Microcontainer] - Re: Alternative JAR extensions
bob.mcwhirter wrote : | So, to me, it seems like a timing issue. The JarUtils.addJarSuffix(...) happens soon enough for JARStructure to see and use it, but *not* soon enough for the HDScanner/Profile/whatever that initially loads the deploy/ directory and constructs the VirtualFile/VFSContext from its children. | | Your test is correct, but isn't quite testing the problem I'm seeing, I think. | Aha, you're right. If the .rails is not there soon enough it will fallback to FileSystemContext. bob.mcwhirter wrote : | Is there some way to register the jar extension extra-early so that the deploy/ directory scanner has it when it's first scanned at boot time? | If you mark one of your deployers as JarExtensionProvider + you put your deployers into deployers directory (the proper way) you should be fine, as deployers are booted before deploy is scanned. -- different boot phases: BOOTSTRAP, DEPLOYERS, APPLICATIONS View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4193219#4193219 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4193219 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
