Given the posts thru Jan 27th on this thread
http://www.jboss.org/index.html?module=bbop=viewtopict=59343
it appears that neither of the following approachs for updating Datasources in
JBoss will in general be workable:
a) Wrap a -ds.xml and driver jar in a .sar and deploy/undeploy that.
b)
[EMAIL PROTECTED] wrote : Ok, that was a great description of the steps.
|
| How about this?
|
| A file is transfered to a directory local to the AdminConsole as described.
Then the Console prepares the input properties for the template to be executed.
Part of the input properties is
[EMAIL PROTECTED] wrote : As for performance - dunno. How fast does
JBoss/Remoting transmit a several megabyte payload :-)
|
Don't have numbers to post, but did want to mention that the current
marshallers used within remoting will actually stream the payload. This means
that it does not
I mean't deployment service should always be invoked with a local url
(file:/../bla.jar). A remote would work too (http://...), as long as
someone can serve it :)
I think we'll be ok, for the first phaze...
View the original post :
We need to first resolve how to upload files into some directory (e.g.
./console/deploy) and have some control over that (i.e. know when uploading is
succesfully completed).
I'll ask Tom to see what the status of this WRT remoting.
A related question I have is how those pages (e.g. JIRA
Guess there are two points from my perspective. The first, which Dimitris
already touched on, what is going to be the interface on the client end? If
this is a web browser, then can just have a servlet for the upload of the jar
(which will obviously not require remoting and should be pretty
anonymous wrote :
| but at least you won't have to load the whole file in memory (which would
have to do otherwise if not streamed).
|
Which is the limitation to this simple fileDrop command I am implementing - the
entire file contents must be shipped to the remote service that will
[EMAIL PROTECTED] wrote :
| What if you need to ship the file to several remote endpoints (as in the
case when you want to remotely write out a config file or deployment sar to
multiple nodes on the network) - you would need mulitple remote streams, no?
Right now, would have to write
Here are a couple of the simpler scenarios...
Case 1: Administering a single JBoss instance which is local to the Admin
Console, i.e. the Admin Console is running inside the instance which is being
administered. This the only case we truely care about for the first phase of
Admin Console
Ok, that was a great description of the steps.
How about this?
A file is transfered to a directory local to the AdminConsole as described.
Then the Console prepares the input properties for the template to be executed.
Part of the input properties is the URL to the local file. When the
[EMAIL PROTECTED] wrote :
| 4) The Admin Console passes the Datasource definition information,
including a URL to the driver jar, into the JBoss Network CommandClient on the
local machine.
| 5) JBoss/Remoting magic happens. What I'm essentially saying is that how
the driver jar gets from
Apologies guys. I was only using a URL to the file as an example of a type of
reference to a file. It might as well have been a String containing the path
relative to JBOSS_HOME, or a java.io.File object.
For the remote case we simply can't rely on the driver jar being available to
the remote
depends on the size of the files. Tom E's idea is a good one for large files -
that is, have a remote file input stream that a server can read to slurp down a
file from the remote client.
My fileDrop command will take the contents of any file (or any String or any
Object to be serialized),
Ok. I'm going to move streaming files lower on my priority list then if you
don't think you would need it right away.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3863166#3863166
Reply to the post :
[EMAIL PROTECTED] wrote : depends on the size of the files. Tom E's idea is
a good one for large files - that is, have a remote file input stream that a
server can read to slurp down a file from the remote client.
So database driver .jar files may typically be around 1-2Mb, with some larger
Wow. Well, this fileDrop is very simple - it slurps in the file contents in a
single byte[] and transmits that byte array over the network (via
JBoss/Remoting transporting and marshalling) to the server. No chunking or
anything.
So, as you can see, the JVM must have enough memory to store
16 matches
Mail list logo
