| Author |
Message |
|
|
Thanks, fellas.
For future reference, in the case that one of us developers has a project that depends on Metc (or anything else) where said project has a conflict resolving an outdated dependency, the developer's fix is as follows.
Include a depMgmt block like this in your pom.xml:
So, since my project depends on some Metc sub-projects, my project's pom.xml includes its dependencies like this:
Maven user group thread regarding this fix:
http://old.nabble.com/I-have-the-right-version,-but-maven-can't-find-it-td28383590.html
SF
|
 |
|
|
Colin, could you please edit the uberPom.xml in the metc repo to reflect this log4j dependency fix so that projects that depend on Metc 1.5 install properly independent of a local Metc build?
Thanks.
- SF
|
 |
|
|
The Metc 1.6 tag has been downloadable for a long time.
See it here:
http://code.marketcetera.org/root/tags/
Yes, there's not much activity here. I'd say the company is focusing on their commercial application and business. It's too bad they haven't released anything publicly in a year. At least we'd have an updated basis for contribution.
|
 |
|
|
Any other suggestions? I was up and running wtih Metc 1.5, have upgraded to 1.6, and now cannot connect photon to ors.
Details here:
http://www.marketcetera.org/community/posts/list/437.page
Help!?
|
 |
|
|
I'd been running Metc 1.5.0 without issue after a few tweaks. I just built 1.6.0 from source successfully, started ORS, and ran as debug the Photon launch. When I try to log in, I receive the following error.
"Unable to connect to the server using the URL 'tcp://192.168.1.100:61616' user name 'admin, host name '192.168.1.100' and post number '9000'..."
Some detail:
- As you can see, I am using the exact 192.168.1.100 ip address as produced by ipconfig.
- ORS had started up successfully and is running heartbeats.
- I used the username/password: admin/admin.
- There is no firewall to be concerned with.
I did notice that "netstat -an" produces the following lines among the set while ORS it not running but I'm not too, too concerned with them as I'm pointing photon to 192.168.1.100 directly:
What am I missing here?
Thanks.
SF
|
 |
|
|
RESOLVED.
I upgraded org.apache.felix dependency in uberPom.xml to version 2.0.0.
per the last comment on:
https://issues.apache.org/jira/browse/FELIX-677?focusedCommentId=12681193&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12681193
|
 |
|
|
Metc 1.5.0 builds successfully on my system. Now, I'm trying to build Metc 1.6.0 and receiving the error in the log below.
I'm doing:
> mvn -f uberPom.xml install
> mvn -DskipTests=true install
It's failing at "Building Photon Third Party Dependency Bundle".
I'd have presumed that there would be some fix that I can make to either of these files:
- C:\marketcetera-platform\source\photon\maven\pom.xml
- C:\marketcetera-platform\source\photon\maven\bundle\pom.xml
...but a diff with each of these in Metc 1.5.0 shows no big changes.
How are others getting around this?
Thanks.
- SF
|
 |
|
|
Ok. Receiver module approach it is then. I already have that running, now need to plug in persistence on it -- was trying to avoid that.
Great. I have direction now. Thanks!
|
 |
|
|
I've got my strategies running and producing Suggestions and I essentially want to persist those the simplest way possible but using an intelligent persistence layer. While looking through the code today, I'd have been happy with a solution of either using the Metc persistence layer or the similar one of my own app by interfacing via the ORS Client API. Seeing that the latter's not possible, what's the best approach?
You mention plumbing to a CEP Module or Photon. We've already touched on Photon in that it uses the ModuleManager. Perhaps I can look at a CEP Module as an example of some other independent actor in the system that can listen on them? I have built a receiver module that can filter for the Suggestion type. If that's a good approach, can I tap into the Metc persistence layer from there?
Thanks again.
|
 |
|
|
I'm managing suggestions more than order executions. Would love if could have used org.marketcetera.client.Client api to listen on this data. Or, if ExecutionReport passed the originating OrderSingle as one of its parameters, I could wrap that obj with some additional context and use that in my Client implementation. Since it doesn't look like those are options...
What's the simplest way to listen for Suggestions from outside of ORS?
I see a pattern of employing the ModuleManager+SinkDataListener in various test classes as well as in photon. If this is the answer, just need a bit of info to get me started... what's needed to get the ModuleManager running?
Thanks.
|
 |
|
|
|
Looking forward to info here as well. Thanks.
|
 |
|
|
|
I'm a Java guy that has played with esper for a month or so. I've found it to be a clearly powerful tool for modeling exactly those things you do already with Java. Recommend giving it a go.
|
 |
|
|
I'm surprised that that's what the issue was, just the cast. I started playing with your eql last night but almost fell asleep on my keyboard and planned to continue with it tonight.
Yes, good advice is to break it down to more simple pieces. That's what I did while debugging mine.
Were you able to find any EQL message boards anywhere? Seems to me that there is a void that needs to be filled there. More than just you and I are playing with this technology independently and a dedicated forum would be useful.
I'll email you tonight. Thanks for the follow-up.
|
 |
|
|
RealTimeMovingAverages java strategy attached.
(edit) Updated the class to pull out some proprietary references. Should work now out of the box.
|
 |
|
|
For what it's worth, I've gotten beyond the issues mentioned here. Esper queries weren't correct. An example real-time 2-4-8 MovingAverages java strategy available here:
http://www.marketcetera.org/community/posts/list/183.page
|
 |
|
|
|
|