[
https://issues.apache.org/activemq/browse/AMQ-744?page=comments#action_36467 ]
Adrian Co commented on AMQ-744:
---
Ive added the vmstat plugin and this is the result it writes:
cpudata index='0' r='1' b='0' w='0' swpd='48952' free='6220' inact='33244'
Hi,
I would be building a C++ layer that would talk to ActiveMQ. Can anybody
guide me as to where I can get some sample C++ code with ActiveMQ.
Regards
Lalit Nagpal
--
View this message in context:
http://www.nabble.com/C%2B%2B-Code-to-talk-to-ActiveMQ-tf1853331.html#a5060078
Sent from the
On 6/26/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Yes modules should first be built
The execeptions are caused by missing deps in the modules. Nothing to
do with the deployment plugin.
Almost there. I was misled by the exception wrt xmlbeans and didn't
apply the patch for the missing deps.
Add custom security manager to disable dangerous things like System.exit()
--
Key: GSHELL-26
URL: http://issues.apache.org/jira/browse/GSHELL-26
Project: GShell (Sandbox)
Type: New Feature
I think if you try again the stax and jsr173 problems will not happen.
It's only after the first clean build in an XMLBeans directory that
they happen. Unfortunately, that may mean they happen on like 10
different modules.
Apparently this is due to errors in the XMLBeans plugin or POM and
David
I got a bit distracted over the weekend. I'll be pushing the release out to the mirror system today
and get the rest of the release work done. I'll plan to update the website tomorrow after the
mirrors have had a chance to catch up.
Cheers,
Matt
On 6/26/06, Aaron Mulder [EMAIL PROTECTED] wrote:
I think if you try again the stax and jsr173 problems will not happen.
It's only after the first clean build in an XMLBeans directory that
they happen. Unfortunately, that may mean they happen on like 10
different modules.
Apparently this is
[
http://issues.apache.org/jira/browse/GERONIMO-2148?page=comments#action_12417752
]
Rick McGuire commented on GERONIMO-2148:
Here's the original discussion thread where these changes were debated:
Alan D. Cabrera wrote:
Rick McGuire wrote:
Ok, on to the next phase of the javamail reorganization. This patch
http://issues.apache.org/jira/browse/GERONIMO-2147
is to remove the javamail-transport module and replace it with
references to the javamail-providers-1.3.1 jar file.
Rick
+1
[
http://issues.apache.org/jira/browse/GERONIMO-2147?page=comments#action_12417756
]
Rick McGuire commented on GERONIMO-2147:
svn diff doesn't seem to handle file/directory deletion particularly well. The
net of all of the Reversed patches is
Project: Apache Geronimo
Status: Open
Assignee: Unassigned
Geronimo Info: Patch Available
Total: 25 items
DATE UPDATED KEY SUMMARY
Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code
Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan
Jan 3
geronino should ignore .DS_Store files in the deploy dir
Key: GERONIMO-2151
URL: http://issues.apache.org/jira/browse/GERONIMO-2151
Project: Geronimo
Type: Bug
Security: public (Regular issues)
[ http://issues.apache.org/jira/browse/GERONIMO-2151?page=all ]
Christoph Sturm updated GERONIMO-2151:
--
type: Improvement (was: Bug)
oops, i created this a bug instead of improvement by mistake. sorry :)
geronino should ignore .DS_Store files in
[
http://issues.apache.org/jira/browse/GERONIMO-2151?page=comments#action_12417806
]
Mario Ruebsam commented on GERONIMO-2151:
-
Geronimo should igrone all files and directories starting with '.' and for some
apps and compaibility issues _ in the
This is not a requirement. There is a patch to build openejb only
when necessary (comment out openejb). Once the 1.2-snapshots (geronimo
and openejb) are published somewhere, we will be able to do :
svn ...
mvn
Until then the following steps must be used -
mvn -Dall=modules
mvn
AFAIK, maven makes sure that it has all the plugins even before
sorting the projects. It can not distinguish the fact that a subset of
the projects do not need the plugin. Ideally maven should distinguish
between a maven plugin and other plugins. If m2 snapshots are
published somewhere, it
These are known problems. comments inline..
--- Prasad Kashyap [EMAIL PROTECTED] wrote:
I got myself a fresh clean checkout of trunk and built just the
modules. I encountered the following problems -
1. The j2ee module compilation failed due to a dependency on ejb spec
jar.
ConduitBridge can malfunction when first of a set of consumers goes away
Key: AMQ-776
URL: https://issues.apache.org/activemq/browse/AMQ-776
Project: ActiveMQ
Type: Bug
Components: Broker
If you haven't already you might want to look at the plugin export
screen in the admin console. A similar screen for collecting the
various user inputs could be provided in an eclipse based wizard.
It would also be nice if a wizard could generate the static block of a
gbean where the
Thanks for your input Paul..
On Jun 26, 2006, at 10:26 AM, Paul McMahan wrote:
If you haven't already you might want to look at the plugin export
screen in the admin console. A similar screen for collecting the
various user inputs could be provided in an eclipse based wizard.
Yes,
On Jun 24, 2006, at 4:10 PM, Jacek Laskowski wrote:
On 6/24/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Gbean wizard would be nice that provides a GBean skeleton and plan.
That raises a question whether GBean skeleton/plan are required at
all? Could that be worked out with annotations (and
Although there are still some problems (such as not running all the
tests) I think we have pretty much all of the build working in m2
except for the assembly stage, due to the lack of an m2 assembly
plugin. I'm not sure of the status of such a plugin, but I'd like to
suggest that we try
What do we need to do to publish these snapshots?
Regards,
Alan
anita kulshreshtha wrote:
This is not a requirement. There is a patch to build openejb only
when necessary (comment out openejb). Once the 1.2-snapshots (geronimo
and openejb) are published somewhere, we will be able to
David Jencks wrote:
Although there are still some problems (such as not running all the
tests) I think we have pretty much all of the build working in m2
except for the assembly stage, due to the lack of an m2 assembly
plugin. I'm not sure of the status of such a plugin, but I'd like to
I'm excited about moving to m2 and have just been waiting on the green
light. As I recall, Anita offered to contribute some wiki doc on
building Geronimo with m2. Is that doc still on its way in or am I
overlooking it?
Best wishes,
Paul
On 6/26/06, David Jencks [EMAIL PROTECTED] wrote:
Here's the status of the assembly plugin.
The geronimo-assembly-plugin is ready and is undergoing tests. It has
only 1 goal, i.e., the installConfig goal. This goal runs thro' the
dependency list in the pom.xml and installs all dependencies of type
car. I have attached a patch of this plugin for
I was unable to attach the zip file of the plugin. Here's the patch.
Cheers
Prasad.
On 6/26/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Here's the status of the assembly plugin.
The geronimo-assembly-plugin is ready and is undergoing tests. It has
only 1 goal, i.e., the installConfig goal.
On 6/26/06, David Jencks [EMAIL PROTECTED] wrote:
Although there are still some problems (such as not running all the
tests) I think we have pretty much all of the build working in m2
except for the assembly stage, due to the lack of an m2 assembly
plugin. I'm not sure of the status of such a
What branch is this on?
IMO, the sooner we get to m2 the better.
--jason
On Jun 26, 2006, at 10:09 AM, David Jencks wrote:
Although there are still some problems (such as not running all the
tests) I think we have pretty much all of the build working in m2
except for the assembly stage,
On 6/26/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
Yes, XBean will allow us to use just POJOs. I plan on starting the
integration work as soon as I get the merged OpenEJB 2.2 code working
in the TCK (hopefully today or tomorrow).
Great! I was thinking about XBean while writing the email and
The trunk
Cheers
Prasad
On 6/26/06, Jason Dillon [EMAIL PROTECTED] wrote:
What branch is this on?
IMO, the sooner we get to m2 the better.
--jason
On Jun 26, 2006, at 10:09 AM, David Jencks wrote:
Although there are still some problems (such as not running all the
tests) I think we have
[ http://issues.apache.org/jira/browse/GSHELL-18?page=all ]
Jason Dillon closed GSHELL-18:
--
Fix Version: 0.0.2
Resolution: Fixed
New command: exec
-
Key: GSHELL-18
URL:
Exec command eats an additional char after finishing
Key: GSHELL-27
URL: http://issues.apache.org/jira/browse/GSHELL-27
Project: GShell (Sandbox)
Type: Bug
Security: public (Regular issues)
Components:
[ http://issues.apache.org/jira/browse/GERONIMO-1882?page=all ]
Joe Bohn closed GERONIMO-1882:
--
Deploy from web console fails with NoSuchOperationException
---
Key: GERONIMO-1882
[ http://issues.apache.org/jira/browse/GERONIMO-1864?page=all ]
Joe Bohn closed GERONIMO-1864:
--
Deploy no longer starts a web application by default
Key: GERONIMO-1864
URL:
On Jun 26, 2006, at 11:05 AM, Jacek Laskowski wrote:
On 6/26/06, David Jencks [EMAIL PROTECTED] wrote:
Although there are still some problems (such as not running all the
tests) I think we have pretty much all of the build working in m2
except for the assembly stage, due to the lack of an m2
David Blevins wrote:
On Jun 25, 2006, at 8:49 PM, Alan D. Cabrera wrote:
Greg Wilkins wrote:
I think the wiki should clarify the patch process for release branches.
Agreed. I have added slight caveats for
New Features:
develop in trunk
patch to current x.y branch (if to be captured in
[
http://issues.apache.org/jira/browse/GERONIMO-1980?page=comments#action_12417888
]
David Jencks commented on GERONIMO-1980:
About the thread pool, perhaps we should consider having a system thread pool
for long lived system level threads such as
I'm whiskers away from finishing the assembly plugin. I am down to the
nitty grittties of ensuring the correct file mode on the various
files and directories. I also have to set and ensure the correct line
endings.
What else ? We have to get maven to apply the patch for the assembly
plugin and
On 6/26/06, David Jencks [EMAIL PROTECTED] wrote:
I'm suggesting that we declare the m1 build obsolete and remove it,
except possibly for the assembly step and perhaps modules where the
tests do not run under m2.
Well, don't get it annoying, but I still don't understand it. Let's
pretend
On 6/26/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Do we have to go thro the RTC for the geronimo-assembly-plugin ? It is
essentially the same code that we had in m1's BaseConfigInstaller.java
modified to be a mojo. That's it.
Is it a fix? Is it applied to the trunk? If the answers are 'no'
[ http://issues.apache.org/jira/browse/GERONIMO-2046?page=all ]
Bill Dudney updated GERONIMO-2046:
--
Attachment: geronimo-cache-2.patch
this patch adds JMS impl to the replicated server
I also did some refactoring so there are some svn commands to
Thanks David.
David Blevins wrote:
On Jun 25, 2006, at 8:49 PM, Alan D. Cabrera wrote:
Greg Wilkins wrote:
I think the wiki should clarify the patch process for release branches.
Agreed. I have added slight caveats for
New Features:
develop in trunk
patch to current x.y branch (if to
maxReconnectAttempts has no effect
--
Key: AMQ-777
URL: https://issues.apache.org/activemq/browse/AMQ-777
Project: ActiveMQ
Type: Bug
Versions: 4.0.1
Reporter: Jonny Wray
I saw this entry in the forums and I'm having
IMO we should have a completely separate tree for our build support
tools. And once the plugins are stable we release them, until they
are stable we make regular snaps, so that the main tree(s) can just
build w/o having to worry about building plugins first.
--jason
On Jun 26, 2006, at
Hey folks,
I want to update the contributors page of the geronimo.apache.org site...
- trtd bgcolor=#f3f4f5Jeff Genender/td
td bgcolor=#f3f4f5Virtuas/td td
bgcolor=#f3f4f5---/td/tr
+ trtd bgcolor=#f3f4f5Jeff Genender/td
td bgcolor=#f3f4f5Savoir
On 6/27/06, Jeff Genender [EMAIL PROTECTED] wrote:
Hey folks,
I want to update the contributors page of the geronimo.apache.org site...
- trtd bgcolor=#f3f4f5Jeff Genender/td
td bgcolor=#f3f4f5Virtuas/td td
bgcolor=#f3f4f5---/td/tr
+ trtd bgcolor=#f3f4f5Jeff
+1 and congratulations!
On Jun 26, 2006, at 7:31 PM, Jeff Genender wrote:
Hey folks,
I want to update the contributors page of the geronimo.apache.org
site...
- trtd bgcolor=#f3f4f5Jeff Genender/td
td bgcolor=#f3f4f5Virtuas/td td
bgcolor=#f3f4f5---/td/tr
+
Thanks!!
Sachin Patel wrote:
+1 and congratulations!
On Jun 26, 2006, at 7:31 PM, Jeff Genender wrote:
Hey folks,
I want to update the contributors page of the geronimo.apache.org site...
- trtd bgcolor=#f3f4f5Jeff Genender/td
td bgcolor=#f3f4f5Virtuas/td
Jacek Laskowski wrote:
On 6/27/06, Jeff Genender [EMAIL PROTECTED] wrote:
Hey folks,
I want to update the contributors page of the geronimo.apache.org site...
- trtd bgcolor=#f3f4f5Jeff Genender/td
td bgcolor=#f3f4f5Virtuas/td td
bgcolor=#f3f4f5---/td/tr
+
I think we should add support to extend the class path from the
config.xml file. Without this it is not possible to add GBeans via a
the configuration.xml using classes not declared in the original
plan. Another problem revolves around extension hooks in services.
It is common for a
FYI, seems that you need to build trunk first (probably until it
fails with a missing plugin), then build the plugins, then rebuild
trunk. Just building m2-plugins pukes with:
snip
[INFO]
[ERROR] BUILD ERROR
[INFO]
Seems like a reasonable thing to have.
Is this an extension to the plan's xsd or just a specialized gbean
that can augment the classpath?
--jason
On Jun 26, 2006, at 5:26 PM, Dain Sundstrom wrote:
I think we should add support to extend the class path from the
config.xml file. Without
Any objections to enabling wiki-rendering for the GERONIMO JIRA project?
This will allow comment and description fields to utilize Confluence-
style wiki markup.
Its basically just a configuration change, done project by project.
I think this is a good idea. Do we need to vote this change
[
http://issues.apache.org/jira/browse/GSHELL-1?page=comments#action_12417940 ]
Jason Dillon commented on GSHELL-1:
---
Still need to hold on to something like JEXL to handle the variable expression
expansion.
Add ${...} parsing to the CommandLineParser;
Update for new OpenEJB 2.2
--
Key: GERONIMO-2152
URL: http://issues.apache.org/jira/browse/GERONIMO-2152
Project: Geronimo
Type: Improvement
Security: public (Regular issues)
Components: OpenEJB
Reporter: Dain Sundstrom
Assigned
[ http://issues.apache.org/jira/browse/GERONIMO-2152?page=all ]
Dain Sundstrom updated GERONIMO-2152:
-
Attachment: openejb-2.2-merge.patch
Update for new OpenEJB 2.2
--
Key: GERONIMO-2152
URL:
I'm sorry but I'm confused about this main build and the plugins
build. I thought they are all one single build like we did in m1 with
all the new(xx).
This is how the build order is specified in the geronimo/pom.xml
modules
modulemodules/module
modulem2-plugins/module
I have finished the work to update the openejb dead-2.2 branch to run
with Geronimo 1.2. The dead-2.2 branch contains a major
rearchitecture of the OpenEJB container system which split the
deployment units from reusable container and this rearchitecture has
already been adopted in OpenEJB
Jason, as for the relativePath, I tried that. It didn't help. Also,
the default value of relativePath is ../pom.xml anyways.
There are a few cases when this will not work, a bug in m2 code AFAIK.
Better to make it explicit IMO.
--jason
So what to do about openejb?
Build fails:
snip
Bliss:~/ws/apache/geronimo/trunk jason$ mvn
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL ERROR
[INFO]
FYI... if I comment the openejb/modules and `mvn install` I get:
snip
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Plugin could not be found - check
Yes, that's the ideal situation and we very much desire it. But here's
what's preventing us
http://issues.apache.org/jira/browse/GERONIMO-1755#action_12371755
http://jira.codehaus.org/browse/MNG-624
Cheers
Prasad
On 6/26/06, Jason Dillon [EMAIL PROTECTED] wrote:
So what to do about openejb?
I don't see what the problem is.
Is this just about putting the version in the parent element? I
don't really like that it has to be there, but I am okay with it and
using the release plugin to manage that value, which is the main
benefit of the release plugin IMO.
Or am I missing
Jeff Genender wrote:
Hey folks,
I want to update the contributors page of the geronimo.apache.org site...
- trtd bgcolor=#f3f4f5Jeff Genender/td
td bgcolor=#f3f4f5Virtuas/td td
bgcolor=#f3f4f5---/td/tr
+ trtd bgcolor=#f3f4f5Jeff Genender/td
td
Jason,
I'm really, REALLY, glad you have taken an interest in m2 migration
:-) Your experience with other such migrations can surely help us.
Alright so now you can guide us.
So we shall hardcode the parent version in all pom.xml and remove
the version. element for that project itself. That
What the heck is up with the xmlbeans plugin?
I keep getting this from the top-level:
snip
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to
http://www.mail-archive.com/dev@geronimo.apache.org/msg25378.html
On 6/26/06, Jason Dillon [EMAIL PROTECTED] wrote:
What the heck is up with the xmlbeans plugin?
I keep getting this from the top-level:
snip
[INFO]
I'm really, REALLY, glad you have taken an interest in m2 migration
:-) Your experience with other such migrations can surely help us.
Alright so now you can guide us.
:-) I need a buildable server too ;-)
So we shall hardcode the parent version in all pom.xml and remove
the version.
Why does it fail the first time? This seems fishy too...
I'm rebuild again to see what it does, but that is painfully slow...
If we really do depend on a development version of the plugin, then
we should either...
Lobby to get the plugin released
or
Checkin and manage our own version
These are the problems I encountered, encountering.
openejb:
1. openejb/modules/pom.xml specified dependency on
tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist. Think it
should use 1.4-SNAPSHOT. It should also add dist.codehaus.org into
it's repository
2.
Why is openejb included in our build at all?
--jason
On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote:
These are the problems I encountered, encountering.
openejb:
1. openejb/modules/pom.xml specified dependency on
tranql-1.3-SNAPSHOT. That version of tranql doesn'tr exist.
Thanks John...done.
John Sisson wrote:
Jeff Genender wrote:
Hey folks,
I want to update the contributors page of the geronimo.apache.org site...
- trtd bgcolor=#f3f4f5Jeff Genender/td
td bgcolor=#f3f4f5Virtuas/td td
bgcolor=#f3f4f5---/td/tr
+ trtd
Maybe 'coz we built it with new2 before ? Not sure.
Cheers
Prasad
On 6/26/06, Jason Dillon [EMAIL PROTECTED] wrote:
Why is openejb included in our build at all?
--jason
On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote:
These are the problems I encountered, encountering.
openejb:
Any idea where the stax:stax-api:1.1.1-dev comes from?
The root pom states that stax:stax-api:1.0 should be used... but the
errors with the xmlbeans plugin all state 1.1.1-dev.
--jason
On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote:
These are the problems I encountered, encountering.
Probably...
But is it really needed to build the sever?
--jason
On Jun 26, 2006, at 8:33 PM, Prasad Kashyap wrote:
Maybe 'coz we built it with new2 before ? Not sure.
Cheers
Prasad
On 6/26/06, Jason Dillon [EMAIL PROTECTED] wrote:
Why is openejb included in our build at all?
--jason
IMO, it should not be in our build at all.
Regards,
Alan
Jason Dillon wrote:
Why is openejb included in our build at all?
--jason
On Jun 26, 2006, at 8:25 PM, Prasad Kashyap wrote:
These are the problems I encountered, encountering.
openejb:
1. openejb/modules/pom.xml
It's clear to me that we need to break out our plugins build and get the
plugins published ASAP. I asked this in another thread, what will it
take to get this published? I don't think that it's too much trouble,
just an RTC to break the plugin out and then we just start publishing
the
Jacek Laskowski wrote:
On 6/26/06, David Jencks [EMAIL PROTECTED] wrote:
I'm suggesting that we declare the m1 build obsolete and remove it,
except possibly for the assembly step and perhaps modules where the
tests do not run under m2.
Well, don't get it annoying, but I still don't
I think that removing the m1 files is a good idea, as it will help
force us to get m2 to build... which really should not take that long
to get functional 100% of the time.
--jason
On Jun 26, 2006, at 9:19 PM, Alan D. Cabrera wrote:
Jacek Laskowski wrote:
On 6/26/06, David Jencks [EMAIL
Are there *any good reasons* why it should be in the build?
If not... then lets remove it.
--jason
On Jun 26, 2006, at 9:13 PM, Alan D. Cabrera wrote:
IMO, it should not be in our build at all.
Regards,
Alan
Jason Dillon wrote:
Why is openejb included in our build at all?
--jason
On
Can you explain in more detail the rearchitecture that was done in this
update? If this from openejb3 does that mean that we can deprecate
openejb3?
Regards,
Alan
Dain Sundstrom wrote:
I have finished the work to update the openejb dead-2.2 branch to run
with Geronimo 1.2. The dead-2.2
OMG, this xmlbeans plugin is really whacked... need to fix that.
Sucks, that you have to do this to build:
while true; do
mvn install
done
Anyone know any details about this 2.0-dev xmlbeans plugin?
--jason
On Jun 26, 2006, at 8:13 PM, Prasad Kashyap wrote:
83 matches
Mail list logo
