On Sep 7, 2006, at 1:06 AM, Andy Piper wrote:
At 06:25 07/09/2006, Jeremy Boynes wrote:
snipping a little ...
Would it be possible to break this down a little - there are changes
in there to the startup code and to the Spring container - is it
possible to separate those so that there is less to tackle in one go?
Sure, although separating these out in patches is a pain. It means
keeping multiple workspaces which then creates merge headaches for me.
For example, are the startup changes really coupled to renaming the
SpringSCA XSD?
Well, the latter are just obvious typos. Barring those the patch in
its totality supports a specific feature for Spring apps. I can
break it up, but I must admit I was assuming that you or Jim would
want to massage it somewhat anyway. Things move so fast in svn at
the moment that if you don't get patches out quick the world has
changed :)
I would rather have small patches to review/apply than a large one
that conflates several issues. It also makes it easier for any
committer to review/apply which means you will get a quicker turn
around making the merge easier.
Some of the changes seem cosmetic (e.g. JavaDoc changes) and these
really are easier to review if kept separate.
? I'm not aware of those.
Stuff like
@@ -248,8 +245,6 @@
/**
* Sets the root to point to a composite in the hierarchy
specified by the given path
- *
- * @throws InvalidCompositePath
*/
private void setCurrentComposite(String compositePath,
CompositeComponent<?> root) throws InvalidCompositePath {
if (compositePath != null) {
in ServletLauncherListener.
Also some of the changes don't seem to fit our coding style
guidelines. I know we're often lax about that but I felt I should
mention it as we're actively trying to improve. You can check this
fairly easily using the "sourcecheck" profile in Maven ("mvn -o -
Psourcecheck").
[ERROR] BUILD ERROR
[INFO]
----------------------------------------------------------------------
--
[INFO] The plugin 'org.apache.maven.plugins:maven-checkstyle-
plugin' does not ex
ist or no valid version could be found
Try without the -o (you may need to rm ~/.m2/repository/org/apache/
maven/plugins/maven-checkstyle-plugin now that the install failed).
I'm happy to plug in to IntelliJ whatever is appropriate, I had
assumed that the idea:idea target would do that, but evidently not.
I tried to adjust my settings based on other code (4 spaces for
indent, no tabs) but obviously something is not quite right. Can
you point me at what needs to go in IntelliJ?
I work on 5 or 6 different open source projects, each with their
own coding styles, so bear with me while I context switch.
Nice thing with IDEA is that you can have separate style sheets per
project. There is one checked in to Tuscany at ~/java/etc/tuscany-
idea-codestyle.xml that can be imported into your project (if you can
figure out how to have idea:idea do that automatically that would be
great).
Can you point me at the recommended way of logging? I could not
immediately find any code that did this.
We need to write logging guidelines I guess. There have been various
emails about this, look for MonitorFactory. The basic idea is that to
log a component:
* defines a monitoring interface that it will call to emit events
* marks that as a dependency with a @Monitor annotation
* an implementation of that interface is injected by the runtime
* the component makes the calls as needed
Look for usages of o.a.t.api.annotation.Monitor for examples
(although there aren't many unfortunately).
Getting to the technical stuff, the big question I have is about
passing in a Map of properties. This seems to go against the IoC
principles of SCA, Tuscany and Spring. Did you consider extending
RuntimeInfo e.g. as SpringRuntimeInfo, adding in something like
getApplicationContext() ? Or perhaps better, adding the
Yeah, if there is a better way of doing this I would be glad to use
it. I did what I could to get stuff working without introducing
core dependencies on spring. Extending RuntimeInfo is fine, it
means more changes to the Launcher but I guess that's ok.
ApplicationContext as a component in the runtime that could be
directly used as a dependency?
Not sure how I inject this from outside the runtime. This was my
big problem. In this specific use case, Spring needs to be in the
driving seat, passing to the Tuscany runtime what it needs to do
further wiring. If you can outline an example of how this would
work that would be great. I must admit that the operation of these
various pieces is far from clear from the javadoc, so I'm sure my
understanding is far less than perfect. Do you have any design docs
for the new architecture?
There are some in SVN in ~/java/sca/doc.
There is a way to take an existing Java object and add it in as a
Tuscany component. The LauncherImpl does this with the
LauncherRuntimeInfo object that it creates - see LauncherImpl near
line 86. Services this component exposes can be wired just like those
from any other component, usually through autowire.
Your Spring host (I'm assuming its a host as you say its in the
driving seat) can add itself or its ApplicationContext as a component
in Tuscany and that would allow any other component to wire to it.
So, for example, SpringComponentTypeLoader would just have an
@Autowire dependency to a AbstractRefreshableApplicationContext (or
whatever interface is implemented by it) that it could use directly.
Once again, thanks for the patch. If you do get a chance to look at a
couple of these things I'll be online tomorrow and able to help get
the changes in.
Thanks. I'll be looking at some of the Spring issues Jim came
across, so the patch will be getting bigger :) This is the problem
in a fast moving environment with deadlines to meet...
BTW the patch does actually solve the problem I was aiming at - we
are now able to run Spring webapps and struts apps with Tuscany
wiring at the back end.
Great - let's work on getting it into SVN. I'll be on IRC today if
that helps, or ping me directly if you want my google address.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
