We wanna use tuscany sdo in application that runs on websphere 6.
Unfortunatelly we found it conflicts with websphere's own sdo api jar( actually
an emf sdo jar : org.eclipse.emf.commonj.sdo_2.1.0.v200609210005.jar).
Since websphere's own jar has higher privillege when loading classes,
Hi
I'm all for sorting out the sample naming to bring more consistency but I
would stop short of recombining the application and extension samples. Simon
is right that there we faced technical dilemmas [1] but I'm sure everything
could be made to work however we wanted to lay these samples out.
On 5/19/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Can we delete tuscany/java/distribution now that our new SCA
distribution is in tuscany/java/sca/distribution?
--
Jean-Sebastien
+1, i've moved it to the sandbox now long with the contrib and doc folders.
Later can delete these
This is in part feedback on the SCA release candidate that ant posted, but
doesn't require a respin, so I won't muddy the vote thread for this.
If I try to verify an archive in the release candidate with gpg --verify
archivename it tells me it cant find the public key.
I had this issue before
[
https://issues.apache.org/jira/browse/TUSCANY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder reassigned TUSCANY-1294:
--
Assignee: ant elder
web.xml of sample-calculator-web is invalid wrt web-app_2_3.dtd
[
https://issues.apache.org/jira/browse/TUSCANY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder closed TUSCANY-1294.
--
Resolution: Fixed
Applied, thanks for the patch!
There's actually a few more of these if you'd be
Ant,
I've had a good poke around and built the source distro and run the tests
successfully. The only potential blocking issue I have found is that absence
of a STATUS file, which it was my understanding should be copied in from
the project's STATUS file into every distribution, but I haven't
Hey many thanks for the prompt and detailed review.
I can't remember exactly about the STATUS file, i think it may be an old
requirement that is no longer necessary. I can find this incubator-general
email [1] about the recent CXF release which included and old and incorrect
status file, and the
There's been talk in the past about removing the requirement for things like
script and dynamic languages to require a .componentType side file to define
the services, references and properties when they can't be introspected.
I'd really like to get support for this into the next release so have
The OSGi support has fallen behind with all the refactoring of the runtime.
The most recent working code was this great sample from Joel [1], but thats
based on the old Tuscany M2 runtime.
Now would be a really good time to get OSGi support going again. Seems like
there's lots of interest in SCA
Kind of related to this JIRA, could the spec/sdo-api module be moved in the
SVN repo from tuscany/java/spec/sdo-api to tuscany/java/sdo/api?
...ant
On 5/14/07, Frank Budinsky (JIRA) tuscany-dev@ws.apache.org wrote:
Better organization of the interfaces and classes in the SDO Java project
[
https://issues.apache.org/jira/browse/TUSCANY-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder closed TUSCANY-1247.
--
Resolution: Fixed
Write release notes for 0.90 release
I think its actually a bug in the jsonrpc binding that its using the
component self reference, but that aside, this still seems odd to me. Just
because a particular binding is on a service how can it be sure that that
same binding will work as a reference? Some binding's don't support
+1 to Scott's point. The spec does not assert that services are only
available outside of a Domain when they are promoted as composite level
services.
Dave
- Original Message -
From: Scott Kurz [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Thursday, May 17, 2007 3:51 PM
This time round, as so much had changed, we didn't include JIRA numbers in
the release docs. It seems like a good thing to do in the future though. If
everyone agrees that this is a good thing we need to be fairly organized
about how we use JIRA otherwise we suffer a lot of pain come release time
Regarding the STATUS document, I think the policy say we must include them,
check [1] on the Release Documentation and STATUS document sessions.
Also our STATUS file is not up to date, and I can take care of helping
updating that after I finish reviewing the rest of the release candidate.
[1] -
[
https://issues.apache.org/jira/browse/TUSCANY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497520
]
Ron Gavlin commented on TUSCANY-513:
Hi Frank,
Please explain the generated getStaticType() method further. Am
I don't think that document says we MUST include the STATUS document. It
says Check status document meaning check that the STATUS doc doesn't say
there are outstanding legal issues that may prevent a release. Even if that
releasemanagement doc did say we must, the doc is still under development
Here are my findings around the 0.9 Release Candidate, my main concern is
with the issues I mentioned in the modules directory of the source.
Samples:
I have tried the standalone samples and the web samples (in jetty and
tomcat).
All samples look OK, with the exceptions of the ones mentioned
Hi,
This seems to be class isolation issue in WebSphere. Are you using Websphere
6.0.x or 6.1? As far as I know, the 6.1 comes with OSGi support which can
help isolate different versions of EMF classes.
How did you make the SDO/EMF jars available to WebSphere, per server or per
application?
It would be good if all subprojects used whatever scheme it is agreed to so
a developer going across projects does not have to think about adjusting.
On 5/21/07, Simon Laws [EMAIL PROTECTED] wrote:
This time round, as so much had changed, we didn't include JIRA numbers in
the release docs. It
I agree with Haleh, we should try to have consistence on areas common to all
Tuscany sub-projects, JIRA, Distributions, Release Process, etc
On 5/21/07, haleh mahbod [EMAIL PROTECTED] wrote:
It would be good if all subprojects used whatever scheme it is agreed to
so
a developer going across
I have done necessary updates to STATUS page [1], and the Incubator Tuscany
page [2]. Note that the changes on the incubator page takes a little while
to get reflect on the live website.
[1] https://svn.apache.org/repos/asf/incubator/tuscany/STATUS
[2]
I checked out the source from the 0.90 tag and it builds fine from an empty
mvn repository on Mac OS X and the reactor summary is clean. I also
randomly chose several of the samples from the distribution binaries
(calculator-script, supplychain, simple-bigbank, implementation-composite)
and they
I have a definite need to get Tuscany+OSGi working, so will be contributing
patches on this over the next month. My first goal is to get host-equinox
functioning. I've got Equinox 3.3 starting from within the test and am
working on a BundleActivator that does the majority of the host work. I'll
Yes, it's intergrated with Tuscany SDO C++.
Next step is to implement a sample for it.
I intend to add some info on wiki before the first release.
Regards,
Adriano Crestani
On 5/21/07, haleh mahbod [EMAIL PROTECTED] wrote:
Hi Adriano,
Is this integrated with SDO C++? Is there a sample for
26 matches
Mail list logo
