David,
Have you taken a quick look at org.apache.axis.wsdl.symboltable stuff?
a very good stand alone example is in
samples/client/DynamicInvoker.java
-- dims
On Mon, 07 Feb 2005 23:43:01 -, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Author: djencks
> Date: Mon Feb 7 15:42:56 2005
> Ne
Just to clue people in on what has been implemented thus far:
We have an HTTP "server" that delegates to an "listener" that looks up
a WSContainer using URL and sends that input/output streams for
processing.
The WSContainer (the web service stack), in turn, delegates to an
EJBContainer.
Essent
On Feb 7, 2005, at 10:44 AM, Dain Sundstrom wrote:
On Feb 7, 2005, at 10:04 AM, David Jencks wrote:
On Feb 7, 2005, at 9:40 AM, Dain Sundstrom wrote:
On Feb 6, 2005, at 11:16 PM, David Jencks wrote:
Well, I need to think about all this some more to completely
understand it, and I don't think we'll
On Mon, 7 Feb 2005, Geir Magnusson Jr wrote:
> "A DeploymentManager running disconnected from its J2EE
> product can only configure modules but not perform administrative
> operations.
> It might not have access to any product resources. If any of the
> administrative
> operations, distribute, st
On Feb 7, 2005, at 10:04 AM, David Jencks wrote:
On Feb 7, 2005, at 9:40 AM, Dain Sundstrom wrote:
On Feb 6, 2005, at 11:16 PM, David Jencks wrote:
Well, I need to think about all this some more to completely
understand it, and I don't think we'll be implementing more generic
naming strategies fo
On Feb 7, 2005, at 1:04 PM, Dain Sundstrom wrote:
On Feb 7, 2005, at 7:34 AM, Geir Magnusson Jr. wrote:
It seems I can "deploy" to a running server and "distribute" to a
non-running server. I understand the technical difference, but I
don't grok why we need this difference, and more importantly,
On Feb 7, 2005, at 10:04 AM, Dain Sundstrom wrote:
On Feb 7, 2005, at 7:34 AM, Geir Magnusson Jr. wrote:
It seems I can "deploy" to a running server and "distribute" to a
non-running server. I understand the technical difference, but I
don't grok why we need this difference, and more importantly,
Dain Sundstrom wrote:
On Feb 6, 2005, at 12:13 PM, David Jencks wrote:
null
*
JCAManagedConnectionFactory
*
gets all MCF deployed in a standalone module.
*
StatelessSessionBean
bar
Great idea.
+100
+100+infinity
Regards,
Alan
On Feb 7, 2005, at 7:34 AM, Geir Magnusson Jr. wrote:
It seems I can "deploy" to a running server and "distribute" to a
non-running server. I understand the technical difference, but I don't
grok why we need this difference, and more importantly, why I can't
"undistribute" in the event of a mist
On Feb 7, 2005, at 9:40 AM, Dain Sundstrom wrote:
On Feb 6, 2005, at 11:16 PM, David Jencks wrote:
Well, I need to think about all this some more to completely
understand it, and I don't think we'll be implementing more generic
naming strategies for a couple of weeks anyway.
For now, I propose:
On Feb 6, 2005, at 12:13 PM, David Jencks wrote:
null
*
JCAManagedConnectionFactory
*
gets all MCF deployed in a standalone module.
*
StatelessSessionBean
bar
Great idea.
+100
Although, I'm not sure we need it right this minute :)
-dain
On Feb 6, 2005, at 11:16 PM, David Jencks wrote:
Well, I need to think about all this some more to completely
understand it, and I don't think we'll be implementing more generic
naming strategies for a couple of weeks anyway.
For now, I propose:
1. replace the two "hardcoded" fields on Configura
On Feb 7, 2005, at 12:10 PM, Aaron Mulder wrote:
Ah, right. I guess we need to start every conversation by
clarifying the terminology. :)
Cool!
I think your scenario makes sense. As
far as I know, we don't have robust handling for CAR files (fully baked
content, configuration, etc.) rig
Ah, right. I guess we need to start every conversation by
clarifying the terminology. :) I think your scenario makes sense. As
far as I know, we don't have robust handling for CAR files (fully baked
content, configuration, etc.) right now. There are also some issues such
as if you crea
On Feb 7, 2005, at 11:22 AM, Aaron Mulder wrote:
If I can try to summarize briefly, here's the main problem with
featureful offline support:
The deployer doesn't know where the server is storing things it
deploys, and doesn't know what configuration engine the server is
using to
decide wh
If I can try to summarize briefly, here's the main problem with
featureful offline support:
The deployer doesn't know where the server is storing things it
deploys, and doesn't know what configuration engine the server is using to
decide where it is storing things and what should
I'm missing some important clue about deployment.
It seems I can "deploy" to a running server and "distribute" to a
non-running server. I understand the technical difference, but I don't
grok why we need this difference, and more importantly, why I can't
"undistribute" in the event of a mistake.
David Jencks wrote:
Well, I need to think about all this some more to completely understand
it, and I don't think we'll be implementing more generic naming
strategies for a couple of weeks anyway.
For now, I propose:
1. replace the two "hardcoded" fields on Configuration with a map
2. go forward
Well, I need to think about all this some more to completely understand
it, and I don't think we'll be implementing more generic naming
strategies for a couple of weeks anyway.
For now, I propose:
1. replace the two "hardcoded" fields on Configuration with a map
2. go forward with my original pr
David Jencks wrote:
Are you suggesting that instead of 2 name parts, domain and server,
Configuration should have a map that different strategies can stuff
things into? That seems quite reasonable.
Yes. So the parent/child relationship for Configurations allows name
structures to be inherited
[ http://issues.apache.org/jira/browse/GERONIMO-290?page=history ]
John Sisson updated GERONIMO-290:
-
Attachment: JettyModuleBuilder_patch.txt
Attached patch for review for
geronimo\modules\jetty-builder\src\java\org\apache\geronimo\jetty\deployment\Jet
On Feb 6, 2005, at 3:31 PM, Jeremy Boynes wrote:
David Jencks wrote:
We need this in a more obvious place than just a JIRA entry.
agreed. You seem to have basic objections to the functionality, so
lets settle those before we document anything further.
I don't have objections to the basic function
22 matches
Mail list logo
