[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [sapphire-dev] Code for editor
|
> We have "bean:" prefixed elements mixed with "sca:" prefixed elements.
Your
> code seems to be assuming that it's one consistent namespace for all
children
> of a given element.
No, there is no such assumption. You just have another occurrence of
mismatched namespace URNs.
In model: urn:switchyard-component-bean:config:1.0
In sample: urn:switchyard-config:test-bean:1.0
In fact, if you go to "component -> simple service -> implementation beans"
in the editor and hit add you will see a new namespace declaration added for
"bean1" with the namespace from the model.
I think you might have easier time debugging your xml bindings if instead of
trying to load the sample and see if all parts show up in the ui, you
instead looked at the sample and tried to use the UI to create the same
document via UI. I think namespace mismatches, extra levels of elements, etc
would be more obvious this way.
Another trick that I often use when debugging xml binding is to open the
same file that you have open in your editor in an xml or a text editor
concurrently, then arrange the two editors one above the other. Eclipse will
make the two editor share the same buffer and changes in one will be visible
in the other. It means you don't have to flip back-n-forth between pages to
check if the binding is doing what it should.
> But I evidently can't define two "XmlNamespace" annotations in a new root
Transforms interface...
Did you figure this out? The @XmlNamespaces annotation allows you to specify
a list of @XmlNamespace annotation. This is one of the more annoying
limitations of Java annotations support. You cannot have more than one
instance of annotation of given type at a given site.
- Konstantin
-----Original Message-----
From: sapphire-dev-bounces@xxxxxxxxxxx
[mailto:sapphire-dev-bounces@xxxxxxxxxxx] On Behalf Of Brian Fitzpatrick
Sent: Monday, April 04, 2011 8:10 AM
To: Sapphire project
Subject: Re: [sapphire-dev] Code for editor
Let me try this again. That last message was sent accidentally.
Hey Konstantin,
Error reporting is good. Means I'm not poking around quite as much in the
dark when I break things. :)
That said, I think I've run into issues with some of the namespace
declarations.
If you look at the newer switchyard.xml file, there are a few cases where
there are mixed namespace prefixes in a particular parent.
This one looks fine, because it's all within a single namespace:
<sca:service name="M1AppService" promote="SimpleService">
<soap:binding.soap>
<soap:port secure="true">MyWebService/SOAPPort</soap:port>
<soap:wsdl description="foobar">service.wsdl</soap:wsdl>
</soap:binding.soap>
</sca:service>
And then this one mixes things:
<sca:component name="SimpleService">
<bean:implementation.bean
class="org.switchyard.example.m1app.SimpleBean"/>
<sca:service name="SimpleService">
<sca:interface.java
interface="org.switchyard.example.m1app.SimpleService"/>
</sca:service>
<sca:reference name="anotherService">
<sca:interface.java
interface="org.switchyard.example.m1app.AnotherService"/>
</sca:reference>
</sca:component>
We have "bean:" prefixed elements mixed with "sca:" prefixed elements. Your
code seems to be assuming that it's one consistent namespace for all
children of a given element.
--Fitz
_______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, SOA-P
JBoss by Red Hat
----- Original Message -----
From: "Brian Fitzpatrick" <bfitzpat@xxxxxxxxxx>
To: "Sapphire project" <sapphire-dev@xxxxxxxxxxx>
Sent: Monday, April 4, 2011 9:07:35 AM
Subject: Re: [sapphire-dev] Code for editor
Hey Konstantin,
Error reporting is good. Means I'm not poking around quite as much in the
dark when I break things. :)
That said, I think I've run into issues with some of the namespace
declarations.
If you look at the newer switchyard.xml file, there are a few cases where
there are mixed namespace prefixes in a particular parent.
This one looks fine, because it's all within a single namespace:
That said, I'm running into some issues. I think
That said, after updating to the latest Sapphire build from Saturday night,
I actually had some issues resolving the namespace errors being reported.
Exceptions like "IComposite.Components : Could not resolve namespace for
sca:component node name." are much more helpful to provide some context for
where these things are popping up, but I'm still wrapping my head around the
namespace declarations a bit. I'm working through them looking at your
"fixed" example. It's an interesting mix of XmlNamespace and XmlRootBinding
annotations, but I'll figure it out. :)
Then I started working through that "transforms" tag in the new
switchyard.xml example... If you look at the two children of "transforms" -
each has a different namespace. "java" and "smooks" are the two there.
<transforms>
<java:transform.java from="msgA" to="msgB"
class="org.examples.transform.AtoBTransform"/>
<smooks:transform.smooks from="msgC" to="msgD">
<smooks:config>stuff</smooks:config>
</smooks:transform.smooks>
</transforms>
What I was looking at doing was having this hierarchy:
ITransforms, which contains lists of ITransformJava and ITransformSmooks
But I evidently can't define two "XmlNamespace" annotations in a new root
Transforms interface...
@XmlNamespace( uri = "urn:switchyard-config:test-java:1.0", prefix = "java"
)
@XmlNamespace( uri = "urn:switchyard-config:test-smooks:1.0", prefix =
"smooks" )
That fails. So I can't bind to two list properties with different
namespaces.
Is there any way to handle this mixed namespace kind of case? Or do you have
any suggestions?
--Fitz
______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, SOA-P
JBoss by Red Hat
----- Original Message -----
From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
To: "Sapphire project" <sapphire-dev@xxxxxxxxxxx>
Sent: Saturday, April 2, 2011 7:30:38 PM
Subject: Re: [sapphire-dev] Code for editor
Brian,
I found three problems:
1. The switchyard.xml file in sample2 uses
"urn:switchyard-config:test-soap:1.0" namespace for binding.soap, while the
XML binding declaration in the model expects
"urn:switchyard-component-soap:config:1.0" namespace.
2. There are several cases where XML binding annotations refer to namespace
prefixes that are not defined. The namespace must be defined (via
@XmlNamespace or @RootXmlBinding annotation) in the model element it is
referenced in. Note that it isn't necessary to exhaustively specify
namespace in every binding declaration. If namespace prefix isn't specified
in a binding, the system will inherit the namespace of the containing XML
element, but if a namespace prefix is used, it must be defined. For brevity,
I typically only define namespaces (and use prefixes in bindings) at
namespace transition points.
3. ISOAPBinding.WsdlDescription property has naming consistency issues
causing impl for ISOAPBinding to not be generated by the annotation
processor.
I used the opportunity presented by this project to improve our error
reporting. In particular, these two improvements should make it easier to
correct such problems in the future...
Bug 341706 - Report unresolvable namespace usage
https://bugs.eclipse.org/bugs/show_bug.cgi?id=341706
Bug 341707 - Report failure to instantiate model element
https://bugs.eclipse.org/bugs/show_bug.cgi?id=341707
I also ran into a curious bug where the binding system gets confused if it
needs to add namespace declaration whose preferred prefix is already
associated with another namespace. That issue is also fixed now...
Bug 341708 - Problem adding a namespace declaration with default prefix that
is already in use
https://bugs.eclipse.org/bugs/show_bug.cgi?id=341708
I am attaching your project with my fixes applied, but I'd like to encourage
you to try out the error detection improvements... Upgrade to build 217 or
newer, stick with your existing source code and follow the runtime error
messages to make the appropriate fixes.
Thanks,
- Konstantin
-----Original Message-----
From: sapphire-dev-bounces@xxxxxxxxxxx
[mailto:sapphire-dev-bounces@xxxxxxxxxxx] On Behalf Of Brian Fitzpatrick
Sent: Friday, April 01, 2011 4:05 PM
To: Sapphire project
Subject: Re: [sapphire-dev] Code for editor
You bet. Have attached. It's the switchyard.xml in the sample2 I'm going
against now.
Thanks for the help!
--Fitz
_______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, SOA-P
JBoss by Red Hat
----- Original Message -----
From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
To: "Sapphire project" <sapphire-dev@xxxxxxxxxxx>
Sent: Friday, April 1, 2011 4:57:50 PM
Subject: Re: [sapphire-dev] Code for editor
> BTW - In less than a week (probably 10-15 hours scattered through the
week), I've
> been able to (with lots of help from yourself) work through most of
> the
issues and
> generate a fairly fully functional editor. I'm quite impressed with
> where
Sapphire
> is at even a 0.3 level, so congrats to you and your team. It's been
> fun to
tinker with.
>
> My goal is to spend some time on Monday writing a blog post about the
> road
so far
> and it's been a pretty positive experience!
That's very good to hear!
Could you attach a zip of your updated source and I will take a look at the
binding issue? Nothing jumps out at me from the snippet, but I have to see
these declarations in the context of other declarations to see what is going
on.
- Konstantin
-----Original Message-----
From: sapphire-dev-bounces@xxxxxxxxxxx
[mailto:sapphire-dev-bounces@xxxxxxxxxxx] On Behalf Of Brian Fitzpatrick
Sent: Friday, April 01, 2011 3:52 PM
To: Sapphire project
Subject: Re: [sapphire-dev] Code for editor
Yeah, not sure there. May have just been the rebuild and update of Sapphire
that did the trick as well.
So now that I'm able to generate a complete XML based on my original sample,
of course they've changed it a bit. It too is a work in progress. My new
sample is much more namespace aware, which is great.
The issue that I've run into is this... I have a chunk of XML like this:
<sca:service name="M1AppService" promote="SimpleService">
<soap:binding.soap>
<soap:port secure="true">MyWebService/SOAPPort</soap:port>
<soap:wsdl description="foobar">service.wsdl</soap:wsdl>
</soap:binding.soap>
</sca:service>
Now I'm picking up the service and its attributes just fine, but for some
reason the editor isn't processing the <soap:binding> element any longer, so
I'm not able to see the port and wsdl values. I have tried a few things,
including defining my ISOAPBinding interface with these annotations:
// *** serverPort ***
@XmlBinding( path = "soap:binding.soap/port" )
@Label( standard = "&Port" )
@NonNullValue
ValueProperty PROP_PORT = new ValueProperty( TYPE, "Port" );
Value<String> getPort();
void setPort( String value );
// *** WSDL ***
@XmlBinding( path = "soap:binding.soap/wsdl" )
@Label( standard = "&WSDL" )
@NonNullValue
ValueProperty PROP_WSDL = new ValueProperty( TYPE, "WSDL" );
Value<String> getWsdl();
void setWsdl( String value );
No matter what I try, whether the path is "soap:binding.soap/soap:port" or
"binding.soap/port" or "soap:port" or just "port" (which is what it was
before), it's not picking up the value of the node. Now I could split it off
into further child nodes, but I think I should be able to bind to a child
node path, shouldn't I?
Any ideas? Thanks in advance and have a great weekend!
BTW - In less than a week (probably 10-15 hours scattered through the week),
I've been able to (with lots of help from yourself) work through most of the
issues and generate a fairly fully functional editor. I'm quite impressed
with where Sapphire is at even a 0.3 level, so congrats to you and your
team. It's been fun to tinker with.
My goal is to spend some time on Monday writing a blog post about the road
so far and it's been a pretty positive experience!
--Fitz
_______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, SOA-P
JBoss by Red Hat
----- Original Message -----
From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
To: "Sapphire project" <sapphire-dev@xxxxxxxxxxx>
Sent: Friday, April 1, 2011 10:41:22 AM
Subject: Re: [sapphire-dev] Code for editor
> That said, when I tried it out I noticed that it didn't generate the
> xmlns on the composite tag (first child of switchyard), so I tried to
> figure out why that is... Turns out that the @XmlNamespace annotation
> has to precede the @GenerateImpl or it won't pick it up. That's a good
> thing to know. :)
Hmm... Your observation seems rather odd. The order of annotations is never
significant. In fact, you cannot even determine the order from API if you
wanted to.
Perhaps you missed the namespace declaration the first time? Sapphire always
places these at the root element (optimized for fewer declarations rather
than narrowest scope).
- Konstantin
-----Original Message-----
From: sapphire-dev-bounces@xxxxxxxxxxx
[mailto:sapphire-dev-bounces@xxxxxxxxxxx] On Behalf Of Brian Fitzpatrick
Sent: Friday, April 01, 2011 7:37 AM
To: Sapphire project
Subject: Re: [sapphire-dev] Code for editor
Hey Konstantin...
It's ok. I've been having fun putting the pieces together and trying it out.
So don't feel too sorry for me. :)
Plus, it seems my twists and turns pointed out a few bugs, which is always
good. :)
So now that I've uninstalled and reinstalled Sapphire, and pulled in your
updated project things seem to be much happier. I need to dive in to see
what changed so I understand it going forward.
That said, when I tried it out I noticed that it didn't generate the xmlns
on the composite tag (first child of switchyard), so I tried to figure out
why that is... Turns out that the @XmlNamespace annotation has to precede
the @GenerateImpl or it won't pick it up. That's a good thing to know. :)
Back down the rabbit hole to see what other damage I can do. :) And thanks
for your patience and all the help!
--Fitz
_______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, SOA-P
JBoss by Red Hat
----- Original Message -----
From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
To: "Sapphire project" <sapphire-dev@xxxxxxxxxxx>
Sent: Thursday, March 31, 2011 6:37:25 PM
Subject: Re: [sapphire-dev] Code for editor
Hi Brian,
I am sorry to see you all twisted up by this.
> Currently it doesn't generate the SOAPBinding class in the generated
> code of .apt_generated, which is perplexing.
This is caused by mismatch of naming of property field, property name,
getter and setter in ISOAPBinding. The annotation processor doesn't yet
intelligently report the problem as source markers. It simply fails and the
impl class doesn't get generated. I opened a bug to track improving this
scenario. There are more details on the specific problems in the bug.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=341564
> And the third issue is the bizarre namespace problem.
You are generally off by a level in your specification of namespace, so you
aren't seeing the effect. Instead of specifying namespace in list property
binding where list entry element's name is defined, you were specifying
namespace inside the list entry on value properties.
Once I fixed namespace declarations, I noticed that we have a framework bug
in usage of namespace prefix in the list property binding. I fixed this
issue.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=341560
You will need to grab build 208 or newer from Hudson.
https://hudson.eclipse.org/hudson/job/sapphire-0.3.x/
> And I'm running into a bizarre DOM Error [snip]
Not sure how this came about. By the time I straightened out the issue in
ISOAPBinding and the issue with namespace, I was able to add dot to the
element name without any problems. Now that I think about this, it may have
been related to the missing ISOAPBinding impl.
Attached is your project with fixes applied. You will need to move to build
208 or newer. Don't try to update your existing install. Uninstall Sapphire
first or start fresh. In addition to the namespace bug fix, we are going
through some modularity work in this release, so I had to update some bundle
and package imports.
With the attached source, I was able to created the XML structure that I
believe you are after. I also able to paste your sample contents into the
editor and have all the parts recognized.
Diff the model interfaces between your version and mine to get a better
sense of the changes I had to make. Let me know if something is still
unclear.
> I suspect that there must be some way of creating sub-components so
> not everything is nested in the switchyard sdef file to the Nth
> degree, which would probably make this easier to comprehend as well.
Yes, there is. You can define a node at the top level, give it an id and
then reference it by that id inside another node. You can define a form with
various parts, then use the include directive to inline it into a section.
You can even split definitions between several files by using the import
directive. The sdef editor in the SDK should help you discover the various
definition types and directives.
> Sorry this is in an e-mail and not in the forum. I couldn't figure out
> how to attach the file in the forum and didn't want to include
> absolutely everything code-wise in [CODE][/CODE] tags. I figured the
> sapphire mailing list was the next best thing.
No problem. I pretty sure there is no way to attach stuff in the forum. A
pretty big limitation, if you ask me. Basic things (like showing a screen
capture) are very awkward.
I hope your further exploration goes a bit smoother. :)
- Konstantin
-----Original Message-----
From: sapphire-dev-bounces@xxxxxxxxxxx
[mailto:sapphire-dev-bounces@xxxxxxxxxxx] On Behalf Of Brian Fitzpatrick
Sent: Thursday, March 31, 2011 12:52 PM
To: sapphire-dev@xxxxxxxxxxx
Subject: [sapphire-dev] Code for editor
Hey Konstantin (and the rest of the Sapphire dev team)...
I'm tired and at my wit's end with this for now. I'm hoping it's something
stupid I'm doing.
Currently it doesn't generate the SOAPBinding class in the generated code of
.apt_generated, which is perplexing. And I'm running into a bizarre DOM
Error where I think it's telling me that my service/bindingsoap element path
is invalid in this exception [1].
The second issue is that if I try to create a tag with a period in it (i.e.
bindingsoap should be binding.soap), it throws a different error.
And the third issue is the bizarre namespace problem. I'm shooting for
creating something like the switchyard.xml file in the sample directory in
the attached project. So far I'm just to the switchyard -> composite ->
service -> binding.soap level in the XML as far as generating it.
I suspect that there must be some way of creating sub-components so not
everything is nested in the switchyard sdef file to the Nth degree, which
would probably make this easier to comprehend as well.
Sorry this is in an e-mail and not in the forum. I couldn't figure out how
to attach the file in the forum and didn't want to include absolutely
everything code-wise in [CODE][/CODE] tags. I figured the sapphire mailing
list was the next best thing.
Thanks in advance for any and all help here. I suspect it's user error, but
have exhausted my options for now.
--Fitz
[1] !ENTRY org.eclipse.sapphire.ui 4 0 2011-03-31 13:42:40.442 !MESSAGE
Invalid Characer Error !STACK 0
org.w3c.dom.DOMException: Invalid Characer Error
at
org.eclipse.wst.xml.core.internal.document.DocumentImpl.createElementNS(Docu
mentImpl.java:400)
at
org.eclipse.sapphire.modeling.xml.XmlElement.addChildElement(XmlElement.java
:531)
at
org.eclipse.sapphire.modeling.xml.XmlElement.addChildElement(XmlElement.java
:559)
at
org.eclipse.sapphire.modeling.xml.StandardXmlListBindingImpl.addUnderlyingOb
ject(StandardXmlListBindingImpl.java:140)
at
org.eclipse.sapphire.modeling.LayeredListBindingImpl.add(LayeredListBindingI
mpl.java:58)
at
org.eclipse.sapphire.modeling.ModelElementList.addNewElement(ModelElementLis
t.java:243)
at
org.eclipse.sapphire.ui.swt.renderer.actions.internal.OutlineNodeAddActionHa
ndlerFactory$AddActionHandler.run(OutlineNodeAddActionHandlerFactory.java:12
5)
at
org.eclipse.sapphire.ui.SapphireActionHandler.execute(SapphireActionHandler.
java:89)
at
org.eclipse.sapphire.ui.SapphireActionLink$1.linkActivated(SapphireActionLin
k.java:125)
at
org.eclipse.sapphire.ui.swt.renderer.internal.formtext.SapphireFormText.acti
vateLink(SapphireFormText.java:1547)
at
org.eclipse.sapphire.ui.swt.renderer.internal.formtext.SapphireFormText.hand
leMouseClick(SapphireFormText.java:1349)
at
org.eclipse.sapphire.ui.swt.renderer.internal.formtext.SapphireFormText.acce
ss$16(SapphireFormText.java:1320)
at
org.eclipse.sapphire.ui.swt.renderer.internal.formtext.SapphireFormText$6.mo
useUp(SapphireFormText.java:440)
at
org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:219)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053)
at
org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4150)
at
org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3739)
at
org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
at
org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.
java:123)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:
196)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(
EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAp
pLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
_______________________________
Brian Fitzpatrick (aka "Fitz")
Senior Software Engineer, SOA-P
JBoss by Red Hat
_______________________________________________
sapphire-dev mailing list
sapphire-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/sapphire-dev
_______________________________________________
sapphire-dev mailing list
sapphire-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/sapphire-dev
_______________________________________________
sapphire-dev mailing list
sapphire-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/sapphire-dev
_______________________________________________
sapphire-dev mailing list
sapphire-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/sapphire-dev
_______________________________________________
sapphire-dev mailing list
sapphire-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/sapphire-dev
_______________________________________________
sapphire-dev mailing list
sapphire-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/sapphire-dev
_______________________________________________
sapphire-dev mailing list
sapphire-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/sapphire-dev
