> |I am thinking that it would be incredibly cool (and usable) to package up
> |services into deployable jar files (perhaps .sar or something).
>
> yes, the xml+class=.sar I don't know... but yes
xml in this term is not service configuration. I did not want to have to
create a new .sar each time I wanted to have the smae service with a minor
config change. I suppose that it could contain actually service config (or
more correctly some tag that references a xml config file in the .sar for
services which contain no extra or static configuation.
a complete side note, it might be nice to have a CommandService or something
like it, which executes through the same channel as a service, but will
unbind itself once it has done it's job. This would be nice for something
that needed to do some thing once (like add to the classpath) then will
never be needed again... any ways, side note.
> |The service deployer and service manager would be collectively responsible
> |for "discovering" services to install. Once the service classes have been
>
> This is misleading, we can call the API (through JMX and/or Adaptors) or we
> can use the scanner.
I am not really sure what you mean by this. Is what I said misleading?
> |loader (probably in there one class loader, perhaps with some extra loaders
> |for dependency libraries too), the manager will ask the
> |configuration service
> |for the services configuration.
>
> I see. The manager might be superflous need to check.
It might be, I was thinking that one component should load, then ask another
to manage it's state. In this case if there was a library loading mechanism
then it would make more sence for a manager type to deal with that. The
deployer would create the ClassLoader for the service, read the descriptor
then call the manager:
serviceManager.addService(ServiceDescriptor, ClassLoader, ...);
or something like that. You are right though, I only started thinking about
this in more detail last night.
> that I don't see (the dynamic part ... worry about JMX etc etc...) please
> explain
I know that currently services are all MBeans. What I mean here is that
services do not really have to provide a MBean interface if they do not want
to. We could provide a simple wrapper around the service which would
introspect to find all operations & attributes.
All that I meant was that if a service did not want to deal with any of the
MBean stuff, but wanted to participate, we could wrap it automatically (and
would have to actually).
Does that make it more or less clear?
> yes I coded that yesterday. It seems *someone* is sending a message and we
> are a few to recieve it. It seems your reception was quite clear, clearer
> than mine, so I thank you for sharing "your dream"...
Well strictly speaking "my dream", is to have services packaged up into .sar
files, allow them to be dynamically deployed and have the configuation of
these services abstracted out.
I have read most of your emails, though durring the week of JavaOne and
perhaps a little after, I had sooooo many messages that I could not get
other work (that pays) done, so I might have missed something.
I have always been into configuation management of one sort. At Mpath
Interactive, I started working on a system called SANITY, System And Network
moNitor ThingY, which was aiming to do what I described above + all
of the bits you are working on and the rest of what JBoss already is. The
purpose of SANITY was to provide a common service-oriented framework for
managing the configuation of services across a very large number of machines
distributed across the country.
I spent some time prototyping this and filled up a few notebooks with ideas,
but never got very far, because I was the only engineer in operations... and
I could not handle the size of it all =|
> I want to drop a config on a web server and upon boot machines get
> their --net-install. There is a library manager that downloads the libs to
> the local file system and does a cvs like check on the time stamps. If
> newer... redownload. This way you can synchronize farms. (god bless the
> javastations I knew the stuff would resurface)
>
> This is the library manager.
That is basically what I am thinking, even to the point of classloaders per
lib, so that if ServiceA depends on Lib-v1.1 and ServiceB depends on
Lib-v1.2 that they could both run in side of the same virtual machine...
though there could be issues with that working.
Also in the SANITY days I needed to load native libraries, so I was planning
on allowing that too. It probably doesn't make much sence to spend much
time on that for JBoss though. But if it is easy it would make life easier
for folks that need to have access to native libs.
> |Everything (except perhaps access to temp, log and data files) would be
> |referenced by URL's, files could be abstracted to FileSystems (perhaps by
> |the openapi's from NetBeans... but I am getting ahead of myself.
>
> you are having a hot flash of reception... please explain the FileSystem
> stuff.
I notice that there are a few <type>.properties which are used to locate
directies via resources. These are most notibly the tmp, log and db
directories.
I migrated to JBoss from WebLogic and was used to setting the locations of
these directories in property files. I was a little appaled at first when I
found out how the were used in JBoss, but I got over it.
I think it would be a good idea to abstract this out into FileSystems, then
configure a FileSystemManager service with a list of FS that it can serve.
These FS could be local, nfs, ftp, cvs whatever.
Services which require access to such a resource lookup the
FileManagerService, ask it for the FS by name, then work off of the
FileSystem API instead of using hard coded file refs or looking up filenames
from the classpath.
> |<server>
> | <!-- define the local file systems that we have access to -->
> | <filesystems>
> | <!-- where temp files will go -->
> | <filesystem name="temp" type="org.jboss...LocalFileSystem"/>
> |
> | <!-- where log files will go-->
> | <filesystem name="log" type="org.jboss...LocalFileSystem"/>
> |
> | <!-- shared files, like jbossmq state and other fluff go here -->
> | <filesystem name="shared" type="org.jboss...LocalFileSystem"/>
>
> I have a problem with all the modules in JBoss desperately clinging to a
> real filesystem wich makes my URL install life so much harder... so I will
> give you more than the benefit of the doubt, I am actually curious now,
> please expand.
The above is just a simple example for what is probably the most common file
system which JBoss needs to function. I put that in the main config, but it
might be better suited to be loaded from a filemanager.sar and the
appropriate configuration.
I looked breifly at the openapi filesystem package, which NetBeans uses and
it looks like it might work out nicely for use in JBoss, though I am not
sure what the licencing issues are with this.
Any ways, by doing something like this it would allow for future use of
other file systems but will avoid dependance on a real local file system.
Does that make sence? I think it would be fairly simply to implement,
though I admit I have not really thought about it for long.
> | <!-- setup core services -->
> | <services>
> | <deployer type="org.jboss...ServiceDeployerImpl"/>
> | <manager type="org.jboss...ServiceManagerImpl"/>
> | <configuration type="org.jboss...FileServiceConfigurationManager"/>
> | </services>
>
> This we do better with the <mbean> stuff today, it is the X-MLet stuff of
> JBoss. I am by the way expanding it to support a URL tag so that a snippet
> can come with the codebase from which to download (i.e. the webserver)...
What I meant here was that this file should only contain the bare minimum to
get the service deployment scheme to work. Logging should probably also be
include in the bare minimum, though there are issues with that I think.
> |This is what I came up with last night when I could not sleep due to these
> |really annoying (and very loud birds outside).
>
> First aliens... then birds... magic I tell you!
I hate the birds. I have lived in the same house for over a year, and
"magically" (as it may be) the week JavaOne started these birds just showed
up in my neighboors yard around midnight and descided to see how loud they
could sing. The second day I thought I was going to pass out due to lack of
sleep.
> Don't apologize, this is great stuff, great stuff...You have an avid reader
> here.
I was sort of worried about your reaction... just a little, but still.
> I will try to code something over the next days, review it when you can.
Sure, I would dig that. I am currently tring to get a release of a new
product out, as well as trying to get JBoss transactions to work with JMS in
a distributed fashion.
> right smack on, kid, you just really impressed me but don't let that go to
> your head, it would kill your capacity to tune in the bird's amplification
> of the transmission.
I was wondering when you were going to notice =)
> So just chill and go easy on the pot for a couple o days, we will make your
^^^
LOL. ;)
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
