Interesting ...
|Howdy, I have been thinking about this for a while (actually I have been
|think about something like this for years, but never really had
|the resource
|to be anything together).
|
|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
|These files
|would have a descriptor that could tell which service classes are available
|and provide some extra metadata, like the name of the configuration they
|should use.
well it would be close to today's XMLet of jboss (jcml files -> jboss.xml)
|On the server side, there is a Service Deployer (and probably a
|Service Manager, though that might be the JMX Agent) as well as a Service
|Configuration Manager.
yes we have the ServiceConfiguration which I completely rewrote yesterday,
it takes a addConfiguration(String url) that can deploy an individual
service. My goal is to cycle individual services, but this is no walk in
the park (at the ClassLoader level). It is a wrapper on the JMX MBean
instanciation. The version in 3.0 works dynamically you can invoke it
through any adaptor, but I like the idea you discuss of a ServiceDeployer
like we have a J2EEDeployer. I did not see this previously but now it is
clear.
|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.
|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.
good idea,
|Services would be JMX MBeans. They could be wrapped in dynamic mbeans, so
yes, they are all MBeans as it is today.
|services do not have to worry about the JMX bits. Blah, blah, blah.
that I don't see (the dynamic part ... worry about JMX etc etc...) please
explain
|First it would make it trivial to integrate thirdparty components, such as
|Tomcat or Jetty. Users would install the base JBoss server, then download
|the optional services which they desire, then simply tell the configuration
|service about the new component and drop a file into the
|deployment directory.
well strictly speaking it is already partially built in JBoss through JMX
and the XMLet mechanisms.
What I am building in 3.0 is the capacity to download the code dynamically
from a URL.
But the XML snippet is already there. Dropping the file might be a good
idea, need to check.
(right now I drop the snippet)
|All of the above components (deployer, manager & config) would be pluggable
|themselves for maximum extensively. I would imaging that the first
|configuration service would work off of files (probably a standard
|.xml file
|for defining properties and such for a service (or services) and a
|method to
|include other urls (such as jetty.xml or log4j.xml).
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"...
|So in the simplest configuration a user could drop a file into the conf
|directory (say log4j.xml) and a file into the deploy directory (say
|log4j.sar). The deployer would be watching for file, find a new file, read
The deployer is in 2 parts, like the deployer for the j2ee applications we
have in there, there is a "deploy()" part that is passive, meaning that you
call it. And there an "autodeployer" part that monitors a given directory
and calls the previous service when something new happens.
Good idea, I need to code it but with 2 parts like it is for the J2EE
deployer, again thank you.
|config manager (as well as the deployer and possibility an extra library
|manager).
the library manager is a biggy.
let me explain.
I am interested in how this plays in a farm. This is where the fantastic
research is...
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.
|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.
|<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.
|
| <!-- 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)...
|The first bits about filesystems could really be the topic for another
|email.
:) I am waiting...
|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 apologize if this is a
|bit scattered, I have lots of ideas floating around in my head
|about this one
|and it is hard to get them into words.
Don't apologize, this is great stuff, great stuff...You have an avid reader
here.
you relax, and you talk some more to the birds... please fine tune the
reception.
I will try to code something over the next days, review it when you can.
|Any ways, comments on this are appreciated. I am not really sure how
|something like this might fit into the schedule, but I am convinced that it
how does it fit into the schedule ? (lol)
|would be a positive move for JBoss. I am also not sure what parts of the
|above are currently handled by JMX or overlap with what Marc is working on.
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.
So just chill and go easy on the pot for a couple o days, we will make your
vision, should I call it our vision already, but out of respect for the
birds I should call it "the" vision, real... just chill and thank those
birds outside your window that "prevent you from sleeping" ...
feed them already! feed them you thankless thug, feed them... don't you see?
marcf
______________________________________________
"Don't push me 'cause I'm close to the edge...
...I am trying not to lose my head"
-- Grand Master Flash, "The Message", 1980 --
______________________________________________
_______________________
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
