Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
on 1-09-26 22.33, Jason Dillon at [EMAIL PROTECTED] wrote: Anyways, the class loader stuff is nice, as it makes it easy to pull in files, but it sucks when you really need to work with a set of files. We can build a system to make accessing such a set network transparent (based on http, rmi, whatever). Lets not reinvent to wheel... it is a really good design. Lets worry about the vehicle and try to find quality parts which will work out of the box or with minor modifications (forks). Do not know if I follow - but if we wanted to store the filesystems structure -in db -then be able to get a distributed filesystem viuw that way ? ... *** hsqldb v.1.61 Find File demo application This application searches files in a database. First, the database must be initialized with a path. All files of this directory and all its subdirectories will be stored in the database. After this is done, the database can be searched for files that match a specific pattern. *** /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Russian Dolls was: RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
I was thinking last night g David came back with the original proposal I did when designing it and I kind of like it. It goes like this, we can 1- keep the current sar format with xml and classes inside. This kind of packaging is heavy and today is prone to class duplication in the different packages that make up the master package. ANT is really good at generating these russian dolls one inside the other and actually the russian doll image is not that good as we can have many jars at the same level. (it is a large family russian doll). 2- generalize the xml snippet usage. All we do is DROP the xml snippet with a classpath entry in there that says what *URL* to use to distribute the code. This way the structure you distribute is the xml skeleton and nothing more, not the classes, never. From a packaging standpoint this is simpler but also from a classloading point of view as we can reference URLCLassLoaders pointer to a repository. This becomes very lightweight, no replication of *code* across the nodes, just a central URL repository and you distribute the xml skeletons across nodes. *that* is deployment. In fact that is already supported in RH (xml only) I mean that it could be generalized to EAR/JAR/WAR so that you never have I can't see my application classes from my web layers etc etc etc we should use the scoped deployment from Dr JUNG and possible (he he) grand unify the classloaders for this as many of you pointed that application will need to see the resources. I will forward the mail from David as it is the source. regards marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jung |, Dr. Christoph |Sent: Thursday, September 27, 2001 3:20 AM |To: '[EMAIL PROTECTED]' |Subject: AW: [JBoss-dev] JBossFilesystemRoot mbean and sar local |directories. (rh/3.0) | | |-Ursprüngliche Nachricht- |Von: David Jencks [mailto:[EMAIL PROTECTED]] |Gesendet: Mittwoch, 26. September 2001 20:41 |An: [EMAIL PROTECTED] |Betreff: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local |directories. (rh/3.0) | |Hmm, I guess I should experiment and see if a url like |jar:jar:http://.../myrar.rar!/path/myjar.jar!/ works to get to the jar |inside a rar... maybe we don't need to unpack these things. | |If I remember my experiments from a while ago, the URL is valid, but there |is no way |to get a sun.net.www.protocol.jar.Handler sitting on a stream that is |extracted by another jar.Handler. The guy who did the name resolution code |was seemingly more intelligent than the guy who did the specific jar |provider ;-) | |But the URL solution generally does not allow services to manipulate the |resource. So a file abstraction or something like that would be more |suitable. | |CGJ | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
- Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 9:03 AM Subject: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) 1. How does your program find its local directory? I don't want to bind anything in jndi, since jndi may not be started when these local directories are copied. I think it's time for the JBossFilesSystemRoot mbean which anyone can use to find the jboss local directory structure. I'm thinking this would be the first mbean loaded, and could be used by everyone else to find where stuff is. For instance, log4j can find its config files, the ServiceDeployer can find where to put local directories, and your app can find where to look for its local directory. Is this OK with everyone? No, as I may not have a usable local filesystem. Resources should be loaded from thread context class loader, not a filesystem. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
| 1. How does your program find its local directory? I don't want to bind | anything in jndi, since jndi may not be started when these local | directories are copied. I think it's time for the JBossFilesSystemRoot | mbean which anyone can use to find the jboss local directory structure. | I'm thinking this would be the first mbean loaded, and could be used by | everyone else to find where stuff is. For instance, log4j can find its | config files, the ServiceDeployer can find where to put local |directories, | and your app can find where to look for its local directory. Is this OK | with everyone? |No, as I may not have a usable local filesystem. Resources should be loaded |from thread context class loader, not a filesystem. You are right. That is true of resources. But I think the example that he took was poorly chosen (config files). But in the case of MQ it still needs a file system to work so it is relevant that we ship it. The point where I am a bit torn is that we want to tell people stop clinging on your FS, make it web friendly (what you talk about) and on the other hand we need to be realistic about the dependencies on FS these days. I view this as an intermediary solution. marcf | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
On 2001.09.26 12:34:31 -0400 Scott M Stark wrote: - Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 9:03 AM Subject: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) 1. How does your program find its local directory? I don't want to bind anything in jndi, since jndi may not be started when these local directories are copied. I think it's time for the JBossFilesSystemRoot mbean which anyone can use to find the jboss local directory structure. I'm thinking this would be the first mbean loaded, and could be used by everyone else to find where stuff is. For instance, log4j can find its config files, the ServiceDeployer can find where to put local directories, and your app can find where to look for its local directory. Is this OK with everyone? No, as I may not have a usable local filesystem. Resources should be loaded from thread context class loader, not a filesystem. ??? Log4j can get its configuration from a classloader resource, so this was a bad example, however you can't deploy anything without making a local copy first... so you need some kind of usable local filesystem. Marc mentioned earlier that instead of relying on looking up system properites like jboss.system.home it would be a good idea to put this info in an mbean. I'm suggesting putting the copy of local directories location in the same mbean. Are you against the idea of copying specific directories out of a sar verbatim? This whole local directory thing was not my idea, however as I understood it David Maplesden, the Jetty guys, and Jason wanted to be able to put a directory in a sar that would be copied literally into the local filesystem for eg. pre-setup databases, config files, native libraries, and presumably things I haven't heard of. The idea is that they would then have a predictable directory structure at a findable root, that they can write stuff into. If there is no local filesystem available, you won't be able to use a feature like this, but I don't know how you can deploy anything into jboss either. I'm more than happy to take it out if you get marc to agree. thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
|This whole local directory thing was not my idea, however as I understood |it David Maplesden, the Jetty guys, and Jason wanted to be able to put a |directory in a sar that would be copied literally into the local filesystem |for eg. pre-setup databases, config files, native libraries, and presumably |things I haven't heard of. The idea is that they would then have a |predictable directory structure at a findable root, that they can write |stuff into. If there is no local filesystem available, you won't be able |to use a feature like this, but I don't know how you can deploy anything |into jboss either. I'm more than happy to take it out if you get marc to |agree. over my dead body kiddo, david, finish it, you got it marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
- Original Message - From: marc fleury [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 10:11 AM Subject: RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) | everyone else to find where stuff is. For instance, log4j can find its | config files, the ServiceDeployer can find where to put local |directories, | and your app can find where to look for its local directory. Is this OK | with everyone? |No, as I may not have a usable local filesystem. Resources should be loaded |from thread context class loader, not a filesystem. You are right. That is true of resources. But I think the example that he took was poorly chosen (config files). But in the case of MQ it still needs a file system to work so it is relevant that we ship it. The point where I am a bit torn is that we want to tell people stop clinging on your FS, make it web friendly (what you talk about) and on the other hand we need to be realistic about the dependencies on FS these days. I view this as an intermediary solution. marcf A filesystem should just be another service just like JDBC. Ideally it should be accessed like any other securable managed resource via a resource factory. This is the direction we should be moving in. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
- Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 10:20 AM Subject: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) directories are copied. I think it's time for the JBossFilesSystemRoot mbean which anyone can use to find the jboss local directory structure. I'm thinking this would be the first mbean loaded, and could be used by everyone else to find where stuff is. For instance, log4j can find its config files, the ServiceDeployer can find where to put local directories, and your app can find where to look for its local directory. Is this OK with everyone? No, as I may not have a usable local filesystem. Resources should be loaded from thread context class loader, not a filesystem. ??? Log4j can get its configuration from a classloader resource, so this was a bad example, however you can't deploy anything without making a local copy first... so you need some kind of usable local filesystem. Marc mentioned earlier that instead of relying on looking up system properites like jboss.system.home it would be a good idea to put this info in an mbean. I'm suggesting putting the copy of local directories location in the same mbean. Are you against the idea of copying specific directories out of a sar verbatim? This whole local directory thing was not my idea, however as I understood it David Maplesden, the Jetty guys, and Jason wanted to be able to put a directory in a sar that would be copied literally into the local filesystem for eg. pre-setup databases, config files, native libraries, and presumably things I haven't heard of. The idea is that they would then have a predictable directory structure at a findable root, that they can write stuff into. If there is no local filesystem available, you won't be able to use a feature like this, but I don't know how you can deploy anything into jboss either. I'm more than happy to take it out if you get marc to agree. thanks david jencks That there has to be a local filesystem is a invalid premise. That this is required for deployment currently is a criticism of our deployment mechanism, not a justification for requiring a filesystem. We need to be able to run configurations of JBoss in environments where there is no fileystem(embedded systems, firewalls, other restricted systems, J2ME, etc.). Sure some services will require a filesystem, but this is no different from a service that requires JNDI or JMS. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
|A filesystem should just be another service just like JDBC. Ideally it |should be |accessed like any other securable managed resource via a resource factory. |This |is the direction we should be moving in. interesting... yes, you are probably right here. marcf | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
On 2001.09.26 13:51:23 -0400 Scott M Stark wrote: - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 10:20 AM Subject: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) directories are copied. I think it's time for the JBossFilesSystemRoot mbean which anyone can use to find the jboss local directory structure. I'm thinking this would be the first mbean loaded, and could be used by everyone else to find where stuff is. For instance, log4j can find its config files, the ServiceDeployer can find where to put local directories, and your app can find where to look for its local directory. Is this OK with everyone? No, as I may not have a usable local filesystem. Resources should be loaded from thread context class loader, not a filesystem. ??? Log4j can get its configuration from a classloader resource, so this was a bad example, however you can't deploy anything without making a local copy first... so you need some kind of usable local filesystem. Marc mentioned earlier that instead of relying on looking up system properites like jboss.system.home it would be a good idea to put this info in an mbean. I'm suggesting putting the copy of local directories location in the same mbean. Are you against the idea of copying specific directories out of a sar verbatim? This whole local directory thing was not my idea, however as I understood it David Maplesden, the Jetty guys, and Jason wanted to be able to put a directory in a sar that would be copied literally into the local filesystem for eg. pre-setup databases, config files, native libraries, and presumably things I haven't heard of. The idea is that they would then have a predictable directory structure at a findable root, that they can write stuff into. If there is no local filesystem available, you won't be able to use a feature like this, but I don't know how you can deploy anything into jboss either. I'm more than happy to take it out if you get marc to agree. thanks david jencks That there has to be a local filesystem is a invalid premise. That this is required for deployment currently is a criticism of our deployment mechanism, not a justification for requiring a filesystem. We need to be able to run configurations of JBoss in environments where there is no fileystem(embedded systems, firewalls, other restricted systems, J2ME, etc.). Sure some services will require a filesystem, but this is no different from a service that requires JNDI or JMS. Hmm, I guess I should experiment and see if a url like jar:jar:http://.../myrar.rar!/path/myjar.jar!/ works to get to the jar inside a rar... maybe we don't need to unpack these things. Scott, does the idea of a mbean providing where the local filesystem is fit in better to your securable resource idea than looking up jboss.system.home and accessing the filesystem? Can you be more specific about what the interface to this system would look like? Would you get files out of it? I'm going to commit (after a couple more tests) what I have now that uses the jboss.system.home directly, so we can play with it, and hopefully a better solution will emerge soon. thanks David Jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
Hmm, I guess I should experiment and see if a url like jar:jar:http://.../myrar.rar!/path/myjar.jar!/ works to get to the jar inside a rar... maybe we don't need to unpack these things. Scott, does the idea of a mbean providing where the local filesystem is fit in better to your securable resource idea than looking up jboss.system.home and accessing the filesystem? Can you be more specific about what the interface to this system would look like? Would you get files out of it? I'm more inclined to access jboss/system/home from JNDI and have this be setup as a filesystem context using the ExternalContext mbean. The interface should be a JNDI DirContext that has attributes for the things one normally obtains from a file. For example, take the jboss/system/home/db/jbossmq/QUEUE.A.dat29 file as a DirContext and there could be the following attributes + QUEUE.A.dat29 | -- lastModified = Date of last modification | -- size = size of file in bytes | -- in = java.io.InputStream for reading the file | -- out = java.io.OutputStream for writing the file | etc. This would require a file system provider implementation for use by JBossNS. The Sun provider does not provide this File independent view of the filesystem. Alternatively, how would the J2EE connector APIs work for exposing a filesystem? I'm going to commit (after a couple more tests) what I have now that uses the jboss.system.home directly, so we can play with it, and hopefully a better solution will emerge soon. Fine for now. However, everyone needs to be thinking about how to limit dependency on the filesystem. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
On 26 Sep, marc fleury wrote: |A filesystem should just be another service just like JDBC. Ideally it |should be |accessed like any other securable managed resource via a resource factory. |This |is the direction we should be moving in. interesting... yes, you are probably right here. I have been thinking a long time of doing this, to be able to legaly access the filesystem from within beans (;-)), but have never had the time to do it. It should be farly easy once we know the API we want, since we already have at least one ra (JMS) to steel and borow from. //Peter marcf | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories.(rh/3.0)
That there has to be a local filesystem is a invalid premise. That this is required for deployment currently is a criticism of our deployment mechanism, not a justification for requiring a filesystem. We need to be able to run configurations of JBoss in environments where there is no fileystem(embedded systems, firewalls, other restricted systems, J2ME, etc.). Sure some services will require a filesystem, but this is no different from a service that requires JNDI or JMS. Lets not fall into the trap Sun did with Java and *limit* the API based on what plafroms do not support. I agree that JNDI is a good choice for look up of such resources, but it is clear that the java.io.File crap is not sufficent for robust file system access. Some thing like the NetBeans FileSystem API: http://www.netbeans.org/download/apis/org/openide/filesystems/doc-files/api.html Not that I have looked into it much, but the concept is solid. Map a fs to a cvs repo, a website (read-only|put, read-write|getput)... --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
|normally obtains from a file. For example, take the |jboss/system/home/db/jbossmq/QUEUE.A.dat29 file as a DirContext and |there could be the following attributes |+ QUEUE.A.dat29 || -- lastModified = Date of last modification || -- size = size of file in bytes || -- in = java.io.InputStream for reading the file || -- out = java.io.OutputStream for writing the file || etc. huh... interesting indeed... this does provide a portable way to access file systems, local or not... interesting you are making the distributed filesystem view of JNDI I love to rap about so much a concrete reality. |Fine for now. However, everyone needs to be thinking about how to limit |dependency on the filesystem. If it is truly distributed it is then just a persistent storage view of things. That is what the filesystem was and will always be... just a 'persistent store' on clumsy disks. We abstract that view in something more web friendly. Once we re-invent the feel of files in the web then we can go back and say files ok but for now you are absolutely right, we need to limit the usage of the files as people understand LOCAL FS which is bad. marcf | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
NetBeans appears to have quite a rich interface after a quick read of the link you provided. But it's an IDE so it has a need for all of that. How rich an interface does JBoss need, I have been just sort of following the emails and not thinking too hard. Did this need start with a desire to load configuration files, or is there more to it? Cheers -Original Message- From: Jason Dillon To: [EMAIL PROTECTED] Sent: 9/26/01 3:20 PM Subject: Re: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0) That there has to be a local filesystem is a invalid premise. That this is required for deployment currently is a criticism of our deployment mechanism, not a justification for requiring a filesystem. We need to be able to run configurations of JBoss in environments where there is no fileystem(embedded systems, firewalls, other restricted systems, J2ME, etc.). Sure some services will require a filesystem, but this is no different from a service that requires JNDI or JMS. Lets not fall into the trap Sun did with Java and *limit* the API based on what plafroms do not support. I agree that JNDI is a good choice for look up of such resources, but it is clear that the java.io.File crap is not sufficent for robust file system access. Some thing like the NetBeans FileSystem API: http://www.netbeans.org/download/apis/org/openide/filesystems/doc-files/ api.html Not that I have looked into it much, but the concept is solid. Map a fs to a cvs repo, a website (read-only|put, read-write|getput)... --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossFilesystemRoot mbean and sar local directories. (rh/3.0)
NetBeans appears to have quite a rich interface after a quick read of the link you provided. But it's an IDE so it has a need for all of that. How rich an interface does JBoss need, I have been just sort of following the emails and not thinking too hard. Did this need start with a desire to load configuration files, or is there more to it? We can not really assume what a service provider will need with respect to file system access, so I would say rich is better. I am just frustrated with the poor fs support from Java nativly. I think that a layer of indirection would really be appropriate when accessing files. As the file could be a native file (java.io.File) or a remoted file (web or cvs or whatever). Java does not really provide a good interface for managing a system of files either. I looked a little a the JNDI FSContext plugin, but it looks like that is very java.io.File specific too. I would like to see an abstraction of a file system used by service applications. I have spent a little time at my current job, writting a simple FileManager to make java.io.File objects more network transparent, but it is a cheesy impl, that serverved only to get the immediate job done. WebOS will need a robust network file system, or rather an absract API to access files to be really successfull. As I remember the WebOS bits from MS were based on a WebFS, or perhaps that was another WebOS... not really sure how many of them there are. Anyways, the class loader stuff is nice, as it makes it easy to pull in files, but it sucks when you really need to work with a set of files. We can build a system to make accessing such a set network transparent (based on http, rmi, whatever). The questions are: has anyone else done it already in open source? does it provide most if not all of the immediate functionality required? is it an active project, if not could we fork it? Lets not reinvent to wheel... it is a really good design. Lets worry about the vehicle and try to find quality parts which will work out of the box or with minor modifications (forks). --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
