Hi,
Jeremy raised a good question to check if we can avoid the "encode" twice.
I'm not sure if we can tell if the string is encoded or not just by parsing
the string itself. For example, I cannot tell "A%20B" is encoded from "A B"
or not because "%" is encoded as "%25".
Thanks,
Raymond
The URLCodec.encode() seems to be the same as java.net.URLEncoder.encode().
But they encode is a different scheme, for example, ' ' --> '+' instead of
"%20".
Thanks,
Raymond
- Original Message -
From: "Jim Marino" <[EMAIL PROTECTED]>
To:
Sent: Friday, July 14, 2006 10:42 PM
Subject:
Jim,
I think it's ok, if I understand it right.
I think the Tuscany runtime components should only know about the
WorkScheduler abstraction. We will configure a Jsr237 or JCA work
scheduler based on the host environment and configure it with an
appropriate work manager provided by the host enviro
On Jul 15, 2006, at 1:45 PM, Meeraj Kunnumpurath wrote:
The injection sequence should be something like,
WorkManager workManager = new ThreadPoolWorkManager(10);
To have the runtime handler the above, we could do:
@Constructor("poolSize")
public ThreadPoolWorkManager(@Property int t
Thanks Meeraj,
I forgot about the abstraction conversation about a week back...So
I'm just thinking about how to get this into a system service. What
do you think of this:
1. Add @Autowire to the Jsr237WorkScheduler constructor as in
@Constructor("workManager")
public Jsr237WorkScheduler(
The injection sequence should be something like,
WorkManager workManager = new ThreadPoolWorkManager(10);
WorkScheduler workScheuler = new Jsr237WorkScheduler(workManager);
AsyncTargetInvoker invoker = new AsyncTargetInvoker(workScheuler); //
Sorry I don't know the signature for the constructor
Jim/Ignacio,
There is abstract called WorkScheduler in the SPI, that hides whether
you are using a JCA or commonj work manager. The two implementations are
JcaWorkScheduler and Jsr237WorkScheduler. The Jsr237WorkScheduler can be
injected with a ThreadPoolWorkManager. This way, depending on the hos
Forgot to mention (you may already know this):
You can use Meeraj's work manager, ThreadPoolWorkManager, as the
system service.
Jim
On Jul 15, 2006, at 1:34 PM, Jim Marino wrote:
Ignacio,
Can you check the package name of WorkManager? It should be
commonj.work.WorkManager as opposed to
Ignacio,
Can you check the package name of WorkManager? It should be
commonj.work.WorkManager as opposed to
javax.resource.spi.work.WorkManager? Using comonj on my machine
compiles and runs.
Once you get past that, you'll need to have the work manager system
service deployed as part of
All I do is to run mvn from chianti/sca, after adding the autowire to
JavaComponentBuilder
- Original Message -
From: "Jim Marino" <[EMAIL PROTECTED]>
To:
Sent: Saturday, July 15, 2006 2:59 PM
Subject: Re: WorkManager in JavaComponentBuilder
On Jul 15, 2006, at 11:45 AM, Ignacio Sil
On Jul 15, 2006, at 11:45 AM, Ignacio Silva-Lepe wrote:
To allow JavaAtomicComponent to create a new
AsyncJavaTargetInvoker, it needs to supply the new target invoker
with a work manager. My first try (which may not be the appropriate
thing to do) was to get a work manager autowired into
To allow JavaAtomicComponent to create a new AsyncJavaTargetInvoker, it needs
to supply the new target invoker with a work manager. My first try (which may
not be the appropriate thing to do) was to get a work manager autowired into
JavaComponentBuilder, which then passes it to JavaAtomicCompone
On Jul 15, 2006, at 9:15 AM, Raymond Feng wrote:
I tried with both SUN and IBM JDK and got the same problem. To
reproduce it, you can just go to "\sca\samples\calculator"
and run "mvn". Running "mvn" from "" is successful since
it uses the jar from "\sca\core\target" instead of local
mave
I tried with both SUN and IBM JDK and got the same problem. To reproduce it,
you can just go to "\sca\samples\calculator" and run "mvn". Running
"mvn" from "" is successful since it uses the jar from
"\sca\core\target" instead of local maven repository.
Here is the printout of JarLocation: fil
On Jul 15, 2006, at 8:35 AM, Jeremy Boynes wrote:
That got me past that but I now get an NPE from PojoOjectFactory
because all entries in initializerFactories are null.
Can you jump onto IRC?
This turned out to be two things:
an @Constructor annotation needed to be present (it shouldn't)
na
That got me past that but I now get an NPE from PojoOjectFactory
because all entries in initializerFactories are null.
Can you jump onto IRC?
--
Jeremy
On Jul 15, 2006, at 8:25 AM, Jim Marino wrote:
Here's the issue: if there is no @Constructor annotation, it
currently attempts to heuristica
Here's the issue: if there is no @Constructor annotation, it
currently attempts to heuristically determine the params, ignoring
@Autowire. I should probably make the heuristic processor be smarter
and understand this. In the meantime, can you put @Constructor (no
name attribute) on the cla
Let me take a look...
On Jul 15, 2006, at 8:16 AM, Jeremy Boynes wrote:
I have a problem with ComponentLoader - when I use:
public ComponentLoader(@Autowire LoaderRegistry registry,
@Autowire StAXPropertyFactory
propertyFactory) {
}
I get:
testBoot2Deploym
I have a problem with ComponentLoader - when I use:
public ComponentLoader(@Autowire LoaderRegistry registry,
@Autowire StAXPropertyFactory
propertyFactory) {
}
I get:
testBoot2Deployment
(org.apache.tuscany.core.deployer.BootstrapDeployerTestCase) Time
e
On Jul 15, 2006, at 7:26 AM, Jeremy Boynes wrote:
There are a couple of places where we need to create an
XMLStreamReader and to do this we are doing
XMLInputFactory.newInstance("javax.xml.stream.XMLInputFactory",
classLoader)
to obtain the factory (the classloader is the runtime classloader
Cool!
It would be good to have a sweep through and clean up the system
services as well as the samples.
I'll start on the loaders.
--
Jeremy
On Jul 14, 2006, at 10:12 PM, Jim Marino wrote:
I've checked in support for constructor-based autowiring. System
components can now do the following:
On Jul 15, 2006, at 7:24 AM, Jim Marino wrote:
You know, I completely missed that. Originally I remembered it
being in there, or assumed it would be, and when I went back
yesterday to implement it I didn't see it and I thought it strange
that it would be left out. I'll need to go back to th
There are a couple of places where we need to create an
XMLStreamReader and to do this we are doing
XMLInputFactory.newInstance("javax.xml.stream.XMLInputFactory",
classLoader)
to obtain the factory (the classloader is the runtime classloader and
this form avoids messing with the TCCL).
I t
You know, I completely missed that. Originally I remembered it being
in there, or assumed it would be, and when I went back yesterday to
implement it I didn't see it and I thought it strange that it would
be left out. I'll need to go back to the spec to make sure it is in
there. Also, I thi
On Jul 14, 2006, at 9:19 PM, Raymond Feng wrote:
Hi,
URL returned from Class.getResource() sometimes does not strictly
conform to RFC2396. As a result, running "mvn" command in
"calculator" folder directly fails with the following the exception.
Please review and apply.
Running from a
I may be missing the point but wasn't this in that chump's proposal
already:
"The property or reference associated with each parameter of a
constructor is identified by name in the @Constructor annotation (if
present), *though the presence of a @Property or @Reference
annotation on the pa
Support secured WSDLs and Schemas
-
Key: TUSCANY-551
URL: http://issues.apache.org/jira/browse/TUSCANY-551
Project: Tuscany
Issue Type: New Feature
Components: Java SCA Axis Binding, Java SCA Tools,
I agree with Rick's proposal that we need to get onto one codebase
for the sake of the project, and with Raymond's and Jeremy's comments
that we must work together as a community to resolve the technical
issues that have been raised on this list regarding some aspects of
the chianti design.
Movin
28 matches
Mail list logo
