[Embedded JBoss Development] - Re: embedded and bootsrap dependencies
by ALRubinger
"emuckenhuber" wrote : Yes, i think it's better under it's own umbrella :)
OK. I'm still not seeing the advantage. Will find you on #jboss-dev tomorrow so we can discuss some more.
"emuckenhuber" wrote : Hmm, we could briefly talk about the deployable as well - as i can tell for sure that ProfileService won't expose a VDF deployment.
| Maybe we want to just rename the VfsVdfDeployableFactory to a DeployableFactory? In the end it should not really matter what deployable is created and i don't think there should be 2 different types - like VdfDeployable and PSDeployable - at the same time.
More to discuss. Keep in mind the idea behind Container/Deployable is to be as generic as possible, as the TCK299 test utils will be leveraging the same contract.
"emuckenhuber" wrote : [OT] out of curiosity - it seems that when creating a deployable you are creating a zip out of the shrinkwrap in-memory archive.
| When i first looked at the archive stuff - i thought you are directly deploying this in-memory VirtualFile. Is there a specific reason why you don't do that?
| Well, as it gets zipped it could be interesting to use that also in standalone testing.
Yeah. VFS is a filesystem abstraction, but MemoryFile does not support the full range of VFSFile operations in the same fashion as from a traditional flat file root. So we use ShrinkWrap to represent the mutable object view of an archive and ultimately flush that to a temp file which becomes the deployable. At that point, Embedded/AS doesn't know/care the difference from where the archive originally came from,and the Embedded suite passed without further issues. For instance, JBossWeb and Hibernate both have filesystem dependent code and may fail when using MemoryFile.
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261165#4261165
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261165
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by alesj
"jesper.pedersen" wrote : Ales, can you describe the use-case for JBANN-43 ? In Papaki you explicit specifies which URL resources you want scanned - each URL can be a file or a directory. Filtering is doing through the Papaki specific metadata.
|
The use case is the example from JIRA issue.
e.g.
All our restrictions are held in Module, but that's mostly impl detail.
The way we expose that is via proper visitor pattern.
e.g.
A user can provide ScanningMetaData on-the-fly,
and we should take that in account when:
* re-creating old serialized AR
* creating AR at runtime
Not to mention resources lookup is *the* use-case where you need to apply visitor pattern.
"jesper.pedersen" wrote :
| For JBANN-44 I think it should be a switch - default to false - as most projects doesn't care about annotation definitions, but rather where a specific annotation is located - e.g. which classes, methods, ...
|
OK, this could be made optional.
"jesper.pedersen" wrote :
| JBANN-45 needs to be handled through plugins for the various methods. Currently we have the exclude / excludeAll parameters for the indexer.
|
That's too simplistic.
You should have a proper abstraction.
"jesper.pedersen" wrote :
| JBANN-46 - Papaki is a standalone library with no dependencies on specific vendor APIs. Adding support for the vfszip: protocol could be done through reflection in order to not create a dependency.
|
I don't like to say this, but I'll still go ahead,
Papaki as it's currently in the trunk, is complete re-invent of the wheel.
Standalone argument doesn't convince me.
And I spent the whole week looking at it and thinking about it how to best integrate it with Deployers,
only to realize that complete re-write is what we should do.
Here is my version of it, which can be quite easily integrated with Deployers,
plus it uses all of the abstraction that are already under JBoss umbrella:
* Reflect -- abstraction between JDK Introspection and Javassist
* MDR - simplifying lookup via Signature
* VFS - resources lookup abstraction and visitor pattern
* ClassLoading - exact class resources visitor pattern
Location: http://anonsvn.jboss.org/repos/jbossas/projects/annotations/branches/AnnEnv/
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261133#4261133
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261133
16 years, 5 months
[Embedded JBoss Development] - Re: ShrinkWrap Export to File
by jaikiran
"ALRubinger" wrote :
| Also, the TMPDPL (temporary name) project in JIRA handles this abstractly, so for instance Archives may be deployed directly:
|
| ...
|
The usecases where i think this functionality of exporting to files is going to be useful, is when ShrinkWrap starts getting used as a tool to dynamically generate archives, replacing the current approach of the jars/archives being built statically through the ant build files (or other tools). So if a project was doing this:
1) Build static jars (Ant scripts) as a separate step
2) Run tests which expect the archives/artifacts to be available on the file system
With the use of ShrinkWrap, the #1 could be completely gone and #2 would assemble the archive dynamically. And if there was an API which could export this dynamically generated archive to the file system, then the rest of the tests could continue to work without having to change to work against ShrinkWrap "Archives". Well, the clients could themselves write a simple util (which really is nothing more than a few lines) which writes out to the filesystem once the Archive is assembled, but i guess almost all clients would at some point of time require such functionality :-)
I guess i am thinking outside the lines of the Archive being used for deploying to some server. In the context of ShrinkWrap being used to create Archives for deploying to the server, the links that you pointed to, are better alternatives.
"ALRubinger" wrote :
| Yep. My feeling at the time (and may still be) was "everything in its place", and flushing the contents of an InputStream to a File (or any other resource) is a generic IO function better suited elsewhere.
I see what you are saying. I haven't actually completely looked at the code/goals of ShrinkWrap, but isn't it already doing some of the IO related stuff? I might be wrong though :-) And yes, i do agree that it's a matter of finding the right place for this API.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261131#4261131
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261131
16 years, 5 months
[Embedded JBoss Development] - Re: embedded and bootsrap dependencies
by emuckenhuber
"ALRubinger" wrote :
| From what I can tell, we'd just be moving the problem, as we have to integrate somewhere. Seems what you're proposing is moving jboss-bootstrap-api-embedded and impl-embedded under the org.jboss.embedded umbrella again (where I had it originally, actually ;)).
|
Yes, i think it's better under it's own umbrella :)
"ALRubinger" wrote :
| As currently set up, this won't affect AS as AS doesn't depend upon it. And AS can't really affect it either; that's why there's the TMPDPL "Container" API. Now api-embedded doesn't have a dependency on even VDF. Container becomes the locked SPI.
|
| Does that solve the backwards-compat issue sufficiently for you?
Hmm, we could briefly talk about the deployable as well - as i can tell for sure that ProfileService won't expose a VDF deployment.
Maybe we want to just rename the VfsVdfDeployableFactory to a DeployableFactory? In the end it should not really matter what deployable is created and i don't think there should be 2 different types - like VdfDeployable and PSDeployable - at the same time.
Is there an additional use for the deployable in general? I guess it would be used when having a DSL attaching the actual deployment descriptor instead of a reference to a xml?
[OT] out of curiosity - it seems that when creating a deployable you are creating a zip out of the shrinkwrap in-memory archive.
When i first looked at the archive stuff - i thought you are directly deploying this in-memory VirtualFile. Is there a specific reason why you don't do that?
Well, as it gets zipped it could be interesting to use that also in standalone testing.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261116#4261116
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261116
16 years, 5 months
[Embedded JBoss Development] - Re: embedded and bootsrap dependencies
by ALRubinger
"emuckenhuber" wrote : This is what i'd like to see in a separate embedded project, as it might be easier to keep this backward compatible. So i'm not much concerned about this affecting AS - it's rather the other way around.
>From what I can tell, we'd just be moving the problem, as we have to integrate somewhere. Seems what you're proposing is moving jboss-bootstrap-api-embedded and impl-embedded under the org.jboss.embedded umbrella again (where I had it originally, actually ;)).
As currently set up, this won't affect AS as AS doesn't depend upon it. And AS can't really affect it either; that's why there's the TMPDPL "Container" API. Now api-embedded doesn't have a dependency on even VDF. Container becomes the locked SPI.
Does that solve the backwards-compat issue sufficiently for you?
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261089#4261089
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261089
16 years, 5 months
[Embedded JBoss Development] - Re: embedded and bootsrap dependencies
by emuckenhuber
"ALRubinger" wrote :
| Well, that's confined to jboss-bootstrap-api-embedded, which is for the Embedded AS. When we say "the bootstrap project itself", what does that really mean?
|
With "the bootstrap project itself" i mean everything in projects/bootstrap/*.
"ALRubinger" wrote :
| I'm open to an argument that the Embedded Bootstrap belongs under the Embedded groupId. But regardless of where the code lives in SVN or its groupId, we can still do releases of it without affecting the AS.
|
Basically the piece i'm arguing should not be there is the "extends Container", as this pulls a user deployment-api into bootstrap.
This is what i'd like to see in a separate embedded project, as it might be easier to keep this backward compatible. So i'm not much concerned about this affecting AS - it's rather the other way around.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261080#4261080
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261080
16 years, 5 months