[
https://issues.apache.org/activemq/browse/AMQ-736?page=comments#action_36232 ]
james strachan commented on AMQ-736:
Have committed your test case - many thanks for that - its here...
[ https://issues.apache.org/activemq/browse/AMQ-522?page=all ]
james strachan updated AMQ-522:
---
Version: 4.0
get ProxyConnectorTest to work
--
Key: AMQ-522
URL:
[ https://issues.apache.org/activemq/browse/AMQ-610?page=all ]
james strachan updated AMQ-610:
---
Version: 4.0
fix the test case FanoutTransportBrokerTest which is failing now due to the
fix for AMQ-607 by making the open of the socket occur in the
[ https://issues.apache.org/activemq/browse/AMQ-665?page=all ]
james strachan updated AMQ-665:
---
Version: 4.0
Error while using management interface on messages with binary data.
[ https://issues.apache.org/activemq/browse/AMQ-626?page=all ]
james strachan updated AMQ-626:
---
Version: 4.0
fix test cases MultipleTestsWithSpring*Test which seem to fail due to another
test keeping a broker/journal open
[ https://issues.apache.org/activemq/browse/AMQ-682?page=all ]
james strachan updated AMQ-682:
---
Version: 4.0
several functions spelled wrong, impairs code readability
-
Key: AMQ-682
[ https://issues.apache.org/activemq/browse/AMQ-539?page=all ]
james strachan updated AMQ-539:
---
Version: 4.0
TEST org.apache.activemq.usecases.ThreeBrokerQueueNetworkUsingTcpTest FAILED
We now have a custom JIRA field to indicate issues which have attached
patches. Please if you are submitting a patch can you check this box
as it will help us to prioritise your issue.
I've updated the contribution guide to reflect this
http://activemq.org/site/contributing.html
--
James
[ https://issues.apache.org/activemq/browse/AMQ-711?page=all ]
Hiram Chirino resolved AMQ-711:
---
Fix Version: 4.0.1
4.1
Resolution: Fixed
Applied patch.. Thanks Niklas!
commit() should not be called while in auto-commit mode
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36239 ]
David Jencks commented on AMQ-731:
--
Resin's tx implementation is wrong. suspend is only supposed to remove the
thread/tx association, not change what resources are enrolled
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36240 ]
Christopher G. Stach II commented on AMQ-731:
-
How would a single connection be used for multiple transaction branches if end
is never called with TMSUSPEND?
[ http://issues.apache.org/jira/browse/GERONIMO-1523?page=all ]
David Jencks updated GERONIMO-1523:
---
Fix Version: 1.1
not sure when, but this got ported to 1.1 and new 1.2
Openejb corba class is included (serialized) in all enc contexts
On 6/4/06, Jason Dillon [EMAIL PROTECTED] wrote:
snip
subversion/libsvn_client/commit.c:873: (apr_err=175002)
svn: Commit failed (details follow):
subversion/libsvn_ra_dav/util.c:296: (apr_err=175002)
svn: MKACTIVITY of '/repos/asf/!svn/act/2d4850ad-6c15-0410-93f7-
d4cfeea00f44': 403 Forbidden
Hi Dave,
I don't have preference for anything wrt the naming so I'm +0 for the
change if it suits you. We'll see how it goes once the conversion's
done. At the moment I think we should rather focus on achieving the
final result (and to be honest the change doesn't buy us much) but
don't want to
On 6/5/06, John Sisson [EMAIL PROTECTED] wrote:
The three votes did not comply with the patched and tested requirement
of the RTC rules.
Correct (that's the topic of another thread to change it).
Those RTC rules were established by Ken, the PMC Chair. The PMC Chair
has the power to
Possibly that the change wasn't discussed so the server rejected it ;)
Um... ya... does the community expect that all changes, even the most
trivial need to be discussed, agreed up, documented in triplicate and
faxed to the four corners of the earth.
Hope not... else we are not going to
On 6/5/06, Jason Dillon [EMAIL PROTECTED] wrote:
Um... ya... does the community expect that all changes, even the most
trivial need to be discussed, agreed up, documented in triplicate and
faxed to the four corners of the earth.
Hope not... else we are not going to get much done.
;-)
Well,
Well, it's personal matter which change is trival and which is not,
isn't it? So, your last resort would be to *not* introduce trivial
changes ;)
I guess...
I think we need to change minotaur refs to people... as infra has
stated that the CNAME for the service should be used instead of the
On 6/2/06, Jason Dillon [EMAIL PROTECTED] wrote:
Do you happen to know of any examples where Retrotranslation fails?
There were some incremental errors getting JAXB2 to work which both
the JAXB2 RI team and Taras (the founder of retrotranslator) helped
fix.
Certainly most things like
The only problem is when one wants to introspect generic arguments.
This is the main problem that happened with jaxb2.
For example in the following construct,
ListMyBean
the MyBean type is not available at runtime.
When using JAXB2 RI, you have to generate your beans with additional
BTW Guillaume pointed me to this thread on IRC - there's a limitation
and workaround when using JAXB2 RI
http://sourceforge.net/forum/forum.php?thread_id=1493919forum_id=513539
On 6/5/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
The only problem is when one wants to introspect generic
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
Anyone know how this report is setup? I'd love a similar report for
ActiveMQ and ServiceMix to help us get patches applied ASAP
On 6/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Project: Apache Geronimo
Status: Open
Assignee: Unassigned
Geronimo Info: Patch Available
Total: 25 items
[
http://issues.apache.org/jira/browse/GERONIMO-2082?page=comments#action_12414748
]
Anita Kulshreshtha commented on GERONIMO-2082:
--
I have tested jetty-builder with only xmlbeans as a dependency using the above
-- xbean-2.0.0.pom
-- and
Hi Matt,
Thanks for posting these results :)
Matt Hogstrom wrote:
Gianny,
I applied your changes to fix the double execution. It looks like the
modifications you made overall improved performance by about 10% (from
1445 to 1591). However, I still see the double execution of the SQL
for
I guess the other consideration is for people outside our project that want to pick up piece parts
(like the Tx manager). Please remember that not all OSes will be able to tolerate super long file
names and these will go into the repo. I know there is some head room but were stealing it from
Hi,
I am trying to build the jetty module. I had to exclude the
following dependencies. All these dependencies have either been removed
or have a different version available at repo1.maven.org/maven2. What
is the best way to handle this? If I do not exclude, I get the error
pasted below :
On Jun 5, 2006, at 3:08 AM, Jason Dillon wrote:
Well, it's personal matter which change is trival and which is not,
isn't it? So, your last resort would be to *not* introduce trivial
changes ;)
I guess...
I think we need to change minotaur refs to people... as infra has
stated that the
Hi Anita,
The license which Sun distributes its binary packages under doesn't provide
for redistribution, preventing Maven from making these packages available
as it does for other packages. The solution is to download the JAR(s) from
java.sun.com and install them locally using 'mvn
Inline
Gianny Damour wrote:
Hi Matt,
Thanks for posting these results :)
Matt Hogstrom wrote:
Gianny,
I applied your changes to fix the double execution. It looks like the
modifications you made overall improved performance by about 10% (from
1445 to 1591). However, I still see the
[ https://issues.apache.org/activemq/browse/AMQ-736?page=all ]
james strachan resolved AMQ-736:
Fix Version: 4.0.1
Resolution: Fixed
Patch and test case applied - many thanks!
Broker is not delivering all messages to slow consumer
On Jun 5, 2006, at 7:11 AM, James Strachan wrote:
Anyone know how this report is setup? I'd love a similar report for
ActiveMQ and ServiceMix to help us get patches applied ASAP
Hi James,
They are nice.
David Blevins created the scripts. You can find them here -- https://
The mail dependency should probably be replaced with the
geronimo-spec-javamail jar file.
Rick
anita kulshreshtha wrote:
Hi,
I am trying to build the jetty module. I had to exclude the
following dependencies. All these dependencies have either been removed
or have a different version
[ https://issues.apache.org/activemq/browse/AMQ-736?page=all ]
james strachan updated AMQ-736:
---
Patch Info: [Patch Available]
added patch available flag
Broker is not delivering all messages to slow consumer
Hi Folks,
After the customary 72 hour voting rule, the vote passes with 7 +1s:
+1 Hiram Chirino
+1 Guillaume Nodet
+1 Bruce Snyder
+1 Adrian Co
+1 Jonas Lim
+1 James Strachan
+1 Fritz Oconer
We will now get incubator pmc approval before going final with the release.
--
Regards,
Hiram
The transaction manager needs uncesseraly ties users to the
TransactionContextManager implementation
Key: GERONIMO-2084
URL: http://issues.apache.org/jira/browse/GERONIMO-2084
[ http://issues.apache.org/jira/browse/GERONIMO-2084?page=all ]
Guillaume Nodet updated GERONIMO-2084:
--
Attachment: GERONIMO-2084.patch
This patch allows the TransactionContextManager to be used from unmanaged
threads
The transaction manager
On 6/5/06, Kevan Miller [EMAIL PROTECTED] wrote:
On Jun 5, 2006, at 7:11 AM, James Strachan wrote:
Anyone know how this report is setup? I'd love a similar report for
ActiveMQ and ServiceMix to help us get patches applied ASAP
Hi James,
They are nice.
David Blevins created the scripts. You
On Jun 5, 2006, at 6:09 AM, anita kulshreshtha wrote:
Hi,
I am trying to build the jetty module. I had to exclude the
following dependencies. All these dependencies have either been
removed
or have a different version available at repo1.maven.org/maven2. What
is the best way to handle
[
http://issues.apache.org/jira/browse/GERONIMO-2083?page=comments#action_12414773
]
David Jencks commented on GERONIMO-2083:
Maven is not processing any upload requests at the moment, the codehaus outage
continues to be a disaster. I'm
Provide a TransactionManager implementation on top of TransactionContextManager
---
Key: GERONIMO-2085
URL: http://issues.apache.org/jira/browse/GERONIMO-2085
Project: Geronimo
Type:
[ https://issues.apache.org/activemq/browse/AMQ-732?page=all ]
james strachan reassigned AMQ-732:
--
Assign To: Hiram Chirino
Infinite recovery loop.
---
Key: AMQ-732
URL:
[ https://issues.apache.org/activemq/browse/AMQ-678?page=all ]
james strachan reassigned AMQ-678:
--
Assign To: Hiram Chirino
MessageCleanup fails with mysql 4.1.x
-
Key: AMQ-678
URL:
[
https://issues.apache.org/activemq/browse/AMQ-732?page=comments#action_36235 ]
Hiram Chirino commented on AMQ-732:
---
How big were the messages? Can the shiped example producer and consumer in the
examples directory reproduce the issue?
Infinite
Here's the discussion on why we had to change the groupIds
http://www.mail-archive.com/dev@geronimo.apache.org/msg19426.html
And here's the JIRA that restructured the POMs and gave those groupIds.
http://issues.apache.org/jira/browse/GERONIMO-1755
I hope I understood what David is saying
[
http://issues.apache.org/jira/browse/GERONIMO-2081?page=comments#action_12414781
]
David Jencks commented on GERONIMO-2081:
Connections closed in queue servlet in rev 411811 (forgot the jira number there)
topic servlet fixed in rev 411836
On 6/5/06, James Strachan [EMAIL PROTECTED] wrote:
I've just added a couple of trivial scripts for ActiveMQ and
ServiceMix - though am not sure if these trivial shell scripts in
gbuild fall under the Geronimo ReviewThenCommit? If there's an issue I
can always move them into the ActiveMQ and
On 6/5/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
On 6/5/06, James Strachan [EMAIL PROTECTED] wrote:
I've just added a couple of trivial scripts for ActiveMQ and
ServiceMix - though am not sure if these trivial shell scripts in
gbuild fall under the Geronimo ReviewThenCommit? If there's an
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36237 ]
Christopher G. Stach II commented on AMQ-731:
-
Comparing Resin's and Geronmio's TransactionManagerImpl suspend methods,
Geronimo's doesn't even suspend the
On Jun 5, 2006, at 9:42 AM, Jacek Laskowski wrote:
On 6/5/06, David Jencks [EMAIL PROTECTED] wrote:
You can see what you (or someone else :-) did in dead-1.2 with e.g.
grep djencks all_changes.log
I think there are 329 changes (I did about 43).
I propose that as we merge, verify the
On Jun 5, 2006, at 9:41 AM, James Strachan wrote:
On 6/5/06, Jacek Laskowski [EMAIL PROTECTED] wrote:
On 6/5/06, James Strachan [EMAIL PROTECTED] wrote:
I've just added a couple of trivial scripts for ActiveMQ and
ServiceMix - though am not sure if these trivial shell scripts in
gbuild
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36238 ]
Christopher G. Stach II commented on AMQ-731:
-
Resin's TransactionImpl.suspend() method, which doesn't exist in Geronimo,
calls XAResource.end(Xid,
+1.
The m2 work in dead-1.2 included modules, deployment-plugin and all
the apps. They all passed tests too. We can consider the m2 work from
dead-1.2 merged when we have got these building and testing
successfully into new trunk.
Cheers
Prasad
On 6/5/06, David Jencks [EMAIL PROTECTED] wrote:
Hi David,
The dependency tags for the the module ID of the server wide datasource in
the Geronimo-web.xml were not required for 1.0, so it is unnatural for user
to know they are required for 1.1. If the upgrader tool doesnt indicate
that, user will just have to go figure that out by luck.
One
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=all ]
Prasad Kashyap updated GERONIMO-2071:
-
Attachment: deployment-plugin.patch
The deployment-plugin.patch (later used by magicGball tests)
Move Geronimo build to M2 (new 1.2 trunk)
[ http://issues.apache.org/jira/browse/GERONIMO-2071?page=all ]
Prasad Kashyap updated GERONIMO-2071:
-
Attachment: applications.patch
applications.patch does not include the console and magicGball reorg.
It also configures surefire in the
I would like to make a new tag, v1.1, for the specs release. This is in
preparation for the Geronimo v1.1 release.
Regards,
Alan
+1
Jacek
On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I would like to make a new tag, v1.1, for the specs release. This is in
preparation for the Geronimo v1.1 release.
Regards,
Alan
--
Jacek Laskowski
http://www.laskowski.net.pl
+1, assuming that these are only for the specs that have actually
changed since 1.0.
thanks
david jencks
On Jun 5, 2006, at 12:29 PM, Alan D. Cabrera wrote:
I would like to make a new tag, v1.1, for the specs release. This
is in preparation for the Geronimo v1.1 release.
Regards,
Alan
+1
Alan D. Cabrera wrote:
I would like to make a new tag, v1.1, for the specs release. This is in
preparation for the Geronimo v1.1 release.
Regards,
Alan
+1 to make the new 1.1 tag
On Jun 5, 2006, at 12:33 PM, David Jencks wrote:
+1, assuming that these are only for the specs that have actually
changed since 1.0.
David, I don't believe we can do that unless we reorganize the tree
such that every spec has a separate trunk, branches, and
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36241 ]
David Jencks commented on AMQ-731:
--
I assume you mean mutliple jta transactions rather than multiple branches of a
single jta transaction. In this case something else such
+1
--jason
-Original Message-
From: Alan D. Cabrera [EMAIL PROTECTED]
Date: Mon, 05 Jun 2006 12:29:11
To:Geronimo dev@geronimo.apache.org
Subject: [RTC] Tag new specs for Geronimo v1.1 release
I would like to make a new tag, v1.1, for the specs release. This is in
preparation for
[ http://issues.apache.org/jira/browse/GERONIMO-2084?page=all ]
Guillaume Nodet updated GERONIMO-2084:
--
Attachment: GERONIMO-2084-bis.patch
This patch will work better (the previous one would fail when resuming a
transaction in an unmanaged
[
https://issues.apache.org/activemq/browse/AMQ-731?page=comments#action_36242 ]
Christopher G. Stach II commented on AMQ-731:
-
It could be multiple transactions or multiple branches. For example, a single
database connection can support X
+1. More inline..
--- Prasad Kashyap [EMAIL PROTECTED] wrote:
+1.
The m2 work in dead-1.2 included modules, deployment-plugin and all
the apps. They all passed tests too. We can consider the m2 work from
dead-1.2 merged when we have got these building and testing
successfully into new
[ https://issues.apache.org/activemq/browse/AMQ-731?page=all ]
Christopher G. Stach II updated AMQ-731:
Attachment: amq-txcontext.patch
This simple patch fixes the whole problem.
Redeliveries don't work with resource adapter and Jencks
I don't think we want to use org.apache.geronimo for everything...
but, I also don't think that we need to worry about the groupId's
right now.
Once we completely move to m2, we will want to rearrange our codebase
and at that time I think we may want to introduce one or two
additional groupId's
Howdy Folks,
I was planing to work on a patch that takes that gbean related modules
in ActiveMQ puts them in
geronimo. I just wanted to make sure that there are no objections to
this. Those gbean modules are mostly just gbean related glue code
which I think make more sense living in Geronimo.
Jason Dillon wrote:
I don't think we want to use org.apache.geronimo for everything...
Can you supply a concrete use case?
but, I also don't think that we need to worry about the groupId's
right now.
Once we completely move to m2, we will want to rearrange our codebase
and at that time I
The specs that have actually changed will get their version
incremented. The root POM that's shared by all the modules will also
get its version incremented.
Regards,
Alan
David Jencks wrote:
+1, assuming that these are only for the specs that have actually
changed since 1.0.
thanks
+1
Alan D. Cabrera wrote:
I would like to make a new tag, v1.1, for the specs release. This is in
preparation for the Geronimo v1.1 release.
Regards,
Alan
It's in the CORBA spec jar.
Regards,
Alan
anita kulshreshtha wrote:
Hi,
Where will I find o.omg.CSI.EstablishContext class ? I am getting
the following while building j2ee-corba configuration :
Thanks
Anita
... 24 more
===
[INFO]
I don't think we want to use org.apache.geronimo for everything...
Can you supply a concrete use case?
Sure, I believe that we will eventually get G split up into a few
smaller chunks.
Probably, one tree of modules, that represents the very core of G,
none of the J2EE bits at all. Then
I think that it's time that we, Yoko, take responsibility for the CORBA
spec jars. After Geronimo releases v1.1, let's plan on moving them over
to Yoko.
Thoughts?
Regards,
Alan
We already use a separate groupId for specs. (o.a.g.specs). We have to
decide between having some 5 top level groupIds under o.a.g versus
having all artifacts for modules, configs, specs, samples, under the
same groupId. I am beginning to think, seeing the latter in the repo
is more confusing.
[
http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12414854
]
David Jencks commented on GERONIMO-2071:
Applied 5 june 2006 applications.patch in rev 411916. However, I had to merge
the pom.xml by hand, and:
- did not skip
On 6/5/06, Jason Dillon [EMAIL PROTECTED] wrote:
I think that is fine, as long as we get the activemq folks here (like
you), to help us keep these gbeans in sync with the latest activemq.
+1
* * *
Completely unrelated... well sorta... I really think we should think
about using activemq
o.a.g.modules (formerly called configs)
o.a.g.xxx (formerly called modules)
o.a.g.plugins
o.a.g.assemblies
o.a.g.applications
o.a.g.specs (has been in use for a while now)
I think this is reasonable for the code-base as it exists now.
--jason
Hiram, I think that's a good idea since that code is so closely tied
to geronimo and can easily be affected by changes to it. Case in
point is that I recently debugged a problem in the geronimo console
due to changes in 1.1 and ended up needing to patch the AMQ gbean
code. I created JIRAs in
On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
The specs that have actually changed will get their version
incremented. The root POM that's shared by all the modules will also
get its version incremented.
We just need to be careful that a mvn deploy at the root does not
rebuild and
Thanks Paul.. I'll put that on my dish too.
On 6/5/06, Paul McMahan [EMAIL PROTECTED] wrote:
Hiram, I think that's a good idea since that code is so closely tied
to geronimo and can easily be affected by changes to it. Case in
point is that I recently debugged a problem in the geronimo
I find it a PITA when the groupId doesn't match the Java package name
for jar files. For modules (FKA configs), I don't have any opinion.
For assemblies, I think we should use o.a.g.
-dain
On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote:
o.a.g.modules (formerly called configs)
o.a.g.xxx
On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
I think that it's time that we, Yoko, take responsibility for the CORBA
spec jars. After Geronimo releases v1.1, let's plan on moving them over
to Yoko.
Thoughts?
I'm leaning towards +1, but what would that mean to Geronimo? Will you
wipe
On Jun 5, 2006, at 2:19 PM, Jason Dillon wrote:
o.a.g.modules (formerly called configs)
o.a.g.xxx (formerly called modules)
o.a.g.plugins
o.a.g.assemblies
o.a.g.applications
o.a.g.specs (has been in use for a while now)
I think this is reasonable for the code-base as it exists now.
I like
AFAIK, all specs poms have been changed and even specs with no code changed
have been upgraded with a minor release to reflect the pom change.
These changes were mainly about unneeded transitive dependencies.
So I think all specs should be re-released.
Cheers,
Guillaume Nodet
Hiram Chirino
On Jun 5, 2006, at 2:32 PM, Dain Sundstrom wrote:
I find it a PITA when the groupId doesn't match the Java package
name for jar files. For modules (FKA configs), I don't have any
opinion. For assemblies, I think we should use o.a.g.
Can you be more specific? What do you want the
On Jun 5, 2006, at 2:37 PM, Guillaume Nodet wrote:
AFAIK, all specs poms have been changed and even specs with no code
changed
have been upgraded with a minor release to reflect the pom change.
These changes were mainly about unneeded transitive dependencies.
So I think all specs should be
+1, I think this is a good idea.
Do you think the minimal rar we are building should move to amq? We
might not be the only ones who would like it :-)
thanks
david jencks
On Jun 5, 2006, at 1:41 PM, Hiram Chirino wrote:
Howdy Folks,
I was planing to work on a patch that takes that gbean
On Jun 5, 2006, at 2:41 PM, David Jencks wrote:
On Jun 5, 2006, at 2:32 PM, Dain Sundstrom wrote:
I find it a PITA when the groupId doesn't match the Java package
name for jar files. For modules (FKA configs), I don't have any
opinion. For assemblies, I think we should use o.a.g.
Can
[
http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12414870
]
David Jencks commented on GERONIMO-2071:
Moved console parts into a new applications/console directory for better m2
build: fixed m1 build so it works with the
On 6/5/06, David Jencks [EMAIL PROTECTED] wrote:
+1 as long as geronimo continues to build :-)
Second that! :-)
+1 for the change if the above statement is in effect.
david jencks
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Hi David,
Not really. We are already building a rar, its the 'general purpose'
we throw all our dependencies in it so that it will work in most app
servers kinda rar. I think I'll let customized rars be the job of
integrators or app servers. I think that this makes sense since it
will not
Hiram Chirino wrote:
On 6/5/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
The specs that have actually changed will get their version
incremented. The root POM that's shared by all the modules will also
get its version incremented.
We just need to be careful that a mvn deploy at the root
[
http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12414879
]
David Jencks commented on GERONIMO-2071:
prasad, the deployment-plugin patch seems to have about 5 copies of each file
in it. Can you try again to produce a
Howdy folks,
Here's a patch that brings in the activemq gbean modules into
geronimo. It's partly what was in activemq 4.x and integrated into
geronimo 1.2-dead merged with the changes in the 3.x branch.
It compiles at least and looks like a reasonable start. Once further
integration work
[
http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12414880
]
David Jencks commented on GERONIMO-2071:
Copied the magic gball files to their locations in the big applications.patch
and add the poms. Commented out the
On Jun 5, 2006, at 4:19 PM, Hiram Chirino wrote:
Howdy folks,
Here's a patch that brings in the activemq gbean modules into
geronimo. It's partly what was in activemq 4.x and integrated into
geronimo 1.2-dead merged with the changes in the 3.x branch.
It compiles at least and looks like a
[
http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12414882
]
David Jencks commented on GERONIMO-2071:
Extracted the poms and classpath.properties for console from big
applications.patch.zip. This should bring complete
NPE when the location inside classpath tag can not be resolved
Key: XBEAN-13
URL: http://issues.apache.org/jira/browse/XBEAN-13
Project: XBean
Type: Bug
Components: server
Versions: 2.4
1 - 100 of 120 matches
Mail list logo
