date:20060809


On 8/9/06, Velladurai, Ashok Kumar [EMAIL PROTECTED] wrote:

Hi all,



I am new to MQ Series, I have a model that my web application running on
JBoss 4.0.2 should be able to send message to a remote MQ (different
server) and receive the same message using a MDB (running in same JBoss)
to process the message. Using ActiveMQ is it possible for me to achieve
this kind of model.


Yes. The sender and the MDB are both JMS clients that can connect to a
remote broker.

Note though that MQSeries is a product from IBM which is a completely
different messaging provider to ActiveMQ :)
--

James
---
http://radio.weblogs.com/0112098/

Re: Implementing prefetchSize=0


Note that to implement the JMS API - the minimum value of prefetch
possible is 1 which means deliver 1 message then wait until an
acknowledgement before delivering another. This is essential to
implement

consumer.setMessageListener()
consumer.receiveNoWait().

Neither of which are possible to implement with a prefetch of zero
which effectively means you cannot dispatch messages to the consumers
at all - they must pull them on demand.

We could implement the method consumer.receive() to block and
explicitly perform a request-response to the broker pulling a message.
With a bit more thought we might figure out a way of implementing
receive(timeout) where if a message is delivered by the broker after
the timeout we give it back to the broker.

Though im with Hiram on this one - I don't think a prefetch of zero
is really needed. Also note that receive() wouldn't solve your use
case since it would deliver you a message on the requested queue
anyway. What you really want is 'receive a message if you can on queue
1, then if not on queue2 then if not on queue 3' which is quite
different to a prefetch of zeron.

You'd be better creating a single consumer which consumes to all 3
queues using a wildard or composite destination or even just a single
queue. Then you might want to create your own DispatchPolicy to decide
which messages get dispatched to which consumers - or write some
reordering logic in a Broker Interceptor to make sure that any 'big
jobs' are reordered to be ahead of any 'small jobs' by waiting a small
amount of time to see if you can reorder things.

i.e. what you really want to do is just reorder messages on a queue
based on their priority. Even if we had a prefetch of zero I don't
think it'll help you much.


On 8/8/06, Pesochinskiy, Vadim (MSCIBARRA)
[EMAIL PROTECTED] wrote:

Hi!

I am trying to figure out how this can be done.

As I understand messages are forwarded by the queue to every consumer
(PrefetchSubscription). As long as number of messages dispatched does
not exceed the prefetchSize, messages are send to the client. As soon as
messages are acked more messages are dispatched to the client.

When I set prefetchSize=0 no messages are ever delivered. In this case
instead of pushing messages from the server, they will have to be
requested by the client every time receive() or receiveNoWait() is
called. Are you OK with this impelementation?

BTW, are you guys convinced that AMQ-855 is an issue that needs to be
resolved? To remind you, I need multiple consumers to implement our
prioriteis requirements. In some cases consumers maybe be idle for a
long time and as a result they hold real-time messages, which otherwise
could to be processed by other consumers.

https://issues.apache.org/activemq/browse/AMQ-855

http://www.nabble.com/forum/ViewPost.jtp?post=5583273framed=y


NOTICE: If received in error, please destroy and notify sender. Sender does not 
intend to waive confidentiality or privilege. Use of this email is prohibited 
when received in error.




--

James
---
http://radio.weblogs.com/0112098/

[jira] Updated: (AMQ-850) add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages

 [ https://issues.apache.org/activemq/browse/AMQ-850?page=all ]

james strachan updated AMQ-850:
---

Summary: add the ability to timeout a consumer to prevent a bad, hung 
or unused consumer consumer from grabbing messages  (was: add the ability to 
timeout a prefetch buffer to prevent a single consumer grabbing messages)
Description: 
If a MessageConsumer is created but not used, it still tends to get its 
prefetch-buffer worth of messages. If it does not process them within a 
specific time the consumer should either be closed, or the messages unacked and 
flushed from the buffer so that the consumer does not hog the messages.

Similarly if a consumer gets a message but then locks up without processing the 
message we should lazily kill the consumer releasing and redelivering all its 
messages

  was:If a MessageConsumer is created but not used, it still tends to get its 
prefetch-buffer worth of messages. If it does not process them within a 
specific time the consumer should either be closed, or the messages unacked and 
flushed from the buffer so that the consumer does not hog the messages.


 add the ability to timeout a consumer to prevent a bad, hung or unused 
 consumer consumer from grabbing messages
 ---

 Key: AMQ-850
 URL: https://issues.apache.org/activemq/browse/AMQ-850
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Reporter: james strachan
 Fix For: 4.2


 If a MessageConsumer is created but not used, it still tends to get its 
 prefetch-buffer worth of messages. If it does not process them within a 
 specific time the consumer should either be closed, or the messages unacked 
 and flushed from the buffer so that the consumer does not hog the messages.
 Similarly if a consumer gets a message but then locks up without processing 
 the message we should lazily kill the consumer releasing and redelivering all 
 its messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (AMQ-855) Add support for prefetchSize = 0

[ 
https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36716 ] 

james strachan commented on AMQ-855:


Andrew I just commented on this thread on why a prefetch of 1 is the lowest 
possible value to have while still fully implementing the JMS spec...

http://www.nabble.com/forum/ViewPost.jtp?post=5583273framed=y

A few further comments...

 Now, you could in theory hack together a pull model by setting prefetch 
 size = 0, so that basically each ack is a request for the next message

Thats a prefetch of 1. With a prefetch of zero no messages would be dispatched 
so there could be no ack :)


 Systems like this need to be designed under the assumption that clients will 
 not behave themselves. 
 They will deadlock themselves, slow down arbitrarily, boxes will go up and 
 down, etc. 
 These things happen all the time in real life and shouldn't have adverse 
 effects on other, well-behaved consumers.

This is a valid problem - a badly behaving consumer can hog a message. However 
changing from a push to pull model or having prefetch of 0 or 1 will not change 
this. A hogged message is a hogged message however the consumer manages to get 
the message (pull or push).

e.g. if we did implement prefetch of zero - which means don't deliver a message 
to a consumer at all - unless they perform a consumer.receive() - even then, 
the consumer could then hang/deadlock and never actually acknowledge or process 
the message.

The workaround to this is to just kill consumers if they take too long to 
process a message - see this JIRA which I think what you really need

http://issues.apache.org/activemq/browse/AMQ-850


 Add support for prefetchSize = 0
 

 Key: AMQ-855
 URL: https://issues.apache.org/activemq/browse/AMQ-855
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 4.0, 4.0.1, 4.0.2
 Environment: any
Reporter: Vadim Pesochinskiy
Priority: Critical
 Fix For: 4.2


 This feature would enable to support following test case:
 2 servers are processing 3 submitted jobs with following processing times 10 
 min, 1 min, 1 min. This sequence should finish in 10 minutes as one service 
 will pick up the 10 minutes job, meanwhile the other one should manage the 
 two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute 
 jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes 
 instead of 10.
 This is simplification of the real scenario where I have about 30 consumers 
 submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems:
  Messages are sitting in prefetch buffer are not available to processors, 
 which results in a lot of idle time.
  Order of processing is random. For some reason Job # 20 is processed after 
 Job # 1500. Since senders are synchronously blocked this can result in 
 time-outs.
  Some requests are real-time, i.e. there is a user waiting, so the system 
 cannot wait, so AMQ-850 does not fix this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Java Service Wrapper or Commons Daemon?


Anyone have any experience of these 2 solutions to know which one is
the best to use when creating a windows/unix service?

http://wrapper.tanukisoftware.org/doc/english/introduction.html
http://jakarta.apache.org/commons/daemon/index.html

It'd be nice to have a service for ActiveMQ - am just not sure which
one we should use.

Clearly the latter is also hosted at Apache so we're more likely to be
able to patch it if it has issues. The latter is also used by Tomcat
so is very well used.

Anyone used both before who could offer feedback?

--

James
---
http://radio.weblogs.com/0112098/

[jira] Commented: (AMQ-850) add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages

2006-08-09 Thread Vadim Pesochinskiy (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-850?page=comments#action_36741 ] 

Vadim Pesochinskiy commented on AMQ-850:


Even with prefetchSize=1 you will already loose 1 message. Somehow people tend 
to assume that loosing 1 message is not a big deal :-). In many cases it is a 
big deal, because there is a client can be waiting for response.

Thinking about this problem as a performance issue seems wrong to me. I think 
of it more like a graceful recovery from crash/bug/hang.

 add the ability to timeout a consumer to prevent a bad, hung or unused 
 consumer consumer from grabbing messages
 ---

 Key: AMQ-850
 URL: https://issues.apache.org/activemq/browse/AMQ-850
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Reporter: james strachan
 Fix For: 4.2


 If a MessageConsumer is created but not used, it still tends to get its 
 prefetch-buffer worth of messages. If it does not process them within a 
 specific time the consumer should either be closed, or the messages unacked 
 and flushed from the buffer so that the consumer does not hog the messages.
 Similarly if a consumer gets a message but then locks up without processing 
 the message we should lazily kill the consumer releasing and redelivering all 
 its messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: [jira] Resolved: (SM-525) Enhancement to ValidateComponent to implement a complete and flexible error handling scheme for schema validation

2006-08-09 Thread Grant McDonald

Do you want a wiki page for examples of this configuration or do you have
existing examples this should be integrated into?

-Original Message-
From: Guillaume Nodet (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Thursday, 10 August 2006 10:24 AM
To: servicemix-dev@geronimo.apache.org
Subject: [jira] Resolved: (SM-525) Enhancement to ValidateComponent to
implement a complete and flexible error handling scheme for schema
validation

 [ https://issues.apache.org/activemq/browse/SM-525?page=all ]

Guillaume Nodet resolved SM-525.

Fix Version/s: 3.0-M3
   Resolution: Fixed
 Assignee: Grant McDonald

Author: gnodet
Date: Wed Aug  9 17:20:48 2006
New Revision: 430194

URL: http://svn.apache.org/viewvc?rev=430194view=rev
Log:
SM-525: Enhancement to ValidateComponent to implement a complete and
flexible error handling scheme for schema validation
Patch provided by Grant McDonald

Added:

incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/se
rvicemix/components/validation/MessageAggregatingErrorHandler.java

incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/se
rvicemix/components/validation/MessageAwareErrorHandler.java
Modified:

incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/se
rvicemix/components/validation/CountingErrorHandler.java

incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/se
rvicemix/components/validation/ValidateComponent.java

incubator/servicemix/trunk/servicemix-components/src/test/java/org/apache/se
rvicemix/components/validation/ValidationTest.java

incubator/servicemix/trunk/servicemix-components/src/test/resources/org/apac
he/servicemix/components/validation/example.xml

 Enhancement to ValidateComponent to implement a complete and flexible
error handling scheme for schema validation

-

 Key: SM-525
 URL: https://issues.apache.org/activemq/browse/SM-525
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-components
 Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD
Reporter: Grant McDonald
 Assigned To: Grant McDonald
 Fix For: 3.0-M3

 Attachments: servicemix-components.zip

   Original Estimate: 30 minutes
  Remaining Estimate: 30 minutes

 The purpose of this enchancement was to provide the following:
 1) Allow error messages to be captured by the ValidateComponent and sent
back as the content of a fault message;
 2) Preserve existing functionality; and
 3) Provide a framework for extending the functionality
 It was noted that the existing functionality only dealt with simple case
valid or not valid schemas.  It was decided to make the standard component
more extensible and functional and as such this code is being contributed
back to the ServiceMix project.  To this end the following changes have been
made and are available in the attached zip file:
 1) Added MessageAwareErrorHandler interface - this interface extends the
org.xml.sax.ErrorHandler interface and adds contracts for determining if the
error handler has errors, whether it captures messages from the validator,
and what message formats it supports.
 2) Refactored CountingErrorHandler to extend from MessageAwareErrorHandler
and implement the above mentioned methods
 3) Created MessageAggregatingErrorHandler - this class aggregates all
warning, error and fatal error messages into an XML format (via CDATA).  It
provides the ability to set the root document path and namespace via
configuration and supports DOMSource, StringSource and String formats for
the encapsulated data.
 4) modified ValidateComponent - added errorHandler property to facilitate
dependency injection, with a default value of CountingErrorHandler to
preserve existing functionality.  Refactored the handling of validation
errors to use the new interfaces.  errorHandlers which do not support the
capturing of messages will use the previous method of sending the DOMResult
back as the fault message content.  errorHandlers which do support the
capture of messages will send the error message xml back as the fault
message content.  The src document is now set as a property on the fault
message.
 Additionally, a null pointer check was added to the init on the
schemaResource.getURL() method call.
 A testcase has been added to ValidationTest and the example.xml in the
validation test/resources package demonstrates the configuration of this
functionality.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] Resolved: (SM-525) Enhancement to ValidateComponent to implement a complete and flexible error handling scheme for schema validation


MMh, that would be nice :)
See http://servicemix.goopen.org/site/validation.html for the wiki page
and you could also take a look at extending the new bridge sample
 (
http://svn.apache.org/repos/asf/incubator/servicemix/trunk/samples/bridge/)
by adding a validation before the xslt transformation.
This could be done by adding a routing-slip as the target of the
eip:pipeline, and
using the validation and xslt components as services on this routing-slip.

Any better idea is welcome :)

On 8/10/06, Grant McDonald [EMAIL PROTECTED] wrote:


Do you want a wiki page for examples of this configuration or do you have
existing examples this should be integrated into?

-Original Message-
From: Guillaume Nodet (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Thursday, 10 August 2006 10:24 AM
To: servicemix-dev@geronimo.apache.org
Subject: [jira] Resolved: (SM-525) Enhancement to ValidateComponent to
implement a complete and flexible error handling scheme for schema
validation


 [ https://issues.apache.org/activemq/browse/SM-525?page=all ]

Guillaume Nodet resolved SM-525.


Fix Version/s: 3.0-M3
   Resolution: Fixed
 Assignee: Grant McDonald

Author: gnodet
Date: Wed Aug  9 17:20:48 2006
New Revision: 430194

URL: http://svn.apache.org/viewvc?rev=430194view=rev
Log:
SM-525: Enhancement to ValidateComponent to implement a complete and
flexible error handling scheme for schema validation
Patch provided by Grant McDonald

Added:


incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/se
rvicemix/components/validation/MessageAggregatingErrorHandler.java


incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/se
rvicemix/components/validation/MessageAwareErrorHandler.java
Modified:


incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/se
rvicemix/components/validation/CountingErrorHandler.java


incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/se
rvicemix/components/validation/ValidateComponent.java


incubator/servicemix/trunk/servicemix-components/src/test/java/org/apache/se
rvicemix/components/validation/ValidationTest.java


incubator/servicemix/trunk/servicemix-components/src/test/resources/org/apac
he/servicemix/components/validation/example.xml



 Enhancement to ValidateComponent to implement a complete and flexible
error handling scheme for schema validation



-

 Key: SM-525
 URL: https://issues.apache.org/activemq/browse/SM-525
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-components
 Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD
Reporter: Grant McDonald
 Assigned To: Grant McDonald
 Fix For: 3.0-M3

 Attachments: servicemix-components.zip

   Original Estimate: 30 minutes
  Remaining Estimate: 30 minutes

 The purpose of this enchancement was to provide the following:
 1) Allow error messages to be captured by the ValidateComponent and sent
back as the content of a fault message;
 2) Preserve existing functionality; and
 3) Provide a framework for extending the functionality
 It was noted that the existing functionality only dealt with simple case
valid or not valid schemas.  It was decided to make the standard component
more extensible and functional and as such this code is being contributed
back to the ServiceMix project.  To this end the following changes have
been
made and are available in the attached zip file:
 1) Added MessageAwareErrorHandler interface - this interface extends the
org.xml.sax.ErrorHandler interface and adds contracts for determining if
the
error handler has errors, whether it captures messages from the validator,
and what message formats it supports.
 2) Refactored CountingErrorHandler to extend from
MessageAwareErrorHandler
and implement the above mentioned methods
 3) Created MessageAggregatingErrorHandler - this class aggregates all
warning, error and fatal error messages into an XML format (via
CDATA).  It
provides the ability to set the root document path and namespace via
configuration and supports DOMSource, StringSource and String formats for
the encapsulated data.
 4) modified ValidateComponent - added errorHandler property to
facilitate
dependency injection, with a default value of CountingErrorHandler to
preserve existing functionality.  Refactored the handling of validation
errors to use the new interfaces.  errorHandlers which do not support the
capturing of messages will use the previous method of sending the
DOMResult
back as the fault message content.  errorHandlers which do support the
capture of messages will send the error message xml back as the fault
message content.  The src document is now set as a property on the fault
message.
 Additionally, a null pointer check

[jira] Created: (GERONIMO-2303) Able to deploy two ejb modules that contain ejb's with the same JNDI Name

Able to deploy two ejb modules that contain ejb's with the same JNDI Name
-

 Key: GERONIMO-2303
 URL: http://issues.apache.org/jira/browse/GERONIMO-2303
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
 Environment: All Supported Platforms
Reporter: Manu T George


When I deploy an ejb Module which contains a CMP and then again I deploy the 
same EJB Module the module gets deployed.
Now When I try accessing from a remote client I will always get the reference 
to the ejb in the second module. If I stop the second EJB Module and use the 
client and try to lookup the ejb remotely then I will get an exception(It will 
be javax.naming.NameNotFoundException if Geronimo-2297 is applied else it will 
be ClassCastException in client and IllegalArgumentException in Server).

Expected behaviour is deployment or startup should fail with 
NameAlreadyBoundException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2303) Able to deploy two ejb modules that contain ejb's with the same JNDI Name

 [ http://issues.apache.org/jira/browse/GERONIMO-2303?page=all ]

Manu T George updated GERONIMO-2303:


  Component/s: OpenEJB
Affects Version/s: 1.1.x

 Able to deploy two ejb modules that contain ejb's with the same JNDI Name
 -

 Key: GERONIMO-2303
 URL: http://issues.apache.org/jira/browse/GERONIMO-2303
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: OpenEJB
Affects Versions: 1.1.x
 Environment: All Supported Platforms
Reporter: Manu T George

 When I deploy an ejb Module which contains a CMP and then again I deploy the 
 same EJB Module the module gets deployed.
 Now When I try accessing from a remote client I will always get the reference 
 to the ejb in the second module. If I stop the second EJB Module and use the 
 client and try to lookup the ejb remotely then I will get an exception(It 
 will be javax.naming.NameNotFoundException if Geronimo-2297 is applied else 
 it will be ClassCastException in client and IllegalArgumentException in 
 Server).
 Expected behaviour is deployment or startup should fail with 
 NameAlreadyBoundException.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2297) ClassCastException on invoking a non existing/Stopped EJB from a remote client.

 [ http://issues.apache.org/jira/browse/GERONIMO-2297?page=all ]

Manu T George updated GERONIMO-2297:


Affects Version/s: 1.1.x
   (was: 1.1)

 ClassCastException on invoking a non existing/Stopped EJB from a remote 
 client.
 ---

 Key: GERONIMO-2297
 URL: http://issues.apache.org/jira/browse/GERONIMO-2297
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: OpenEJB
Affects Versions: 1.1.x
 Environment: All Platforms
Reporter: Manu T George
 Attachments: DeploymentIndex.patch


 When I invoke a stopped/nonexisting EJB from an remote client then I get a 
 ClassCastException instead of an exception saying that the EJB is not 
 started/or does not exist
 The exception is shown below
 Client Side
 java.lang.ClassCastException
 at org.openejb.client.JNDIContext.lookup(JNDIContext.java:277)
 at javax.naming.InitialContext.lookup(Unknown Source)
 at examples.cmp.ProductClient.main(ProductClient.java:28)
 Server Side
 12:15:12,483 ERROR [JndiRequestHandler] JNDI request error
 java.lang.IllegalArgumentException: uri path must be in the form 
 [groupId]/[arti
 factId]/[version]/[type] : /ProductRemote
 at 
 org.apache.geronimo.gbean.AbstractNameQuery.init(AbstractNameQuery.
 java:104)
 at 
 org.openejb.DeploymentIndex.getDeploymentIndex(DeploymentIndex.java:2
 06)
 at 
 org.openejb.DeploymentIndex$$FastClassByCGLIB$$d76635c8.invoke(gener
 ated)
 at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
 at 
 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod
 Invoker.java:38)
 at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
 n.java:122)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
 java:817)
 at 
 org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5
 7)
 at 
 org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat
 ionInvoker.java:35)
 at 
 org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro
 xyMethodInterceptor.java:96)
 at 
 org.openejb.DeploymentIndex$$EnhancerByCGLIB$$7b6484b7.getDeploymentI
 ndex(generated)
 at 
 org.openejb.server.ejbd.JndiRequestHandler.doLookup(JndiRequestHandle
 r.java:175)
 at 
 org.openejb.server.ejbd.JndiRequestHandler.processRequest(JndiRequest
 Handler.java:111)
 at org.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:154)
 at org.openejb.server.ejbd.EjbServer.service(EjbServer.java:87)
 at 
 org.openejb.server.ejbd.EjbServer$$FastClassByCGLIB$$d379d2ff.invoke(
 generated)
 at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
 at 
 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod
 Invoker.java:38)
 at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio
 n.java:122)
 at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.
 java:817)
 at 
 org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5
 7)
 at 
 org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat
 ionInvoker.java:35)
 at 
 org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro
 xyMethodInterceptor.java:96)
 at 
 org.activeio.xnet.ServerService$$EnhancerByCGLIB$$c7de235e.service(g
 enerated)
 at org.activeio.xnet.ServicePool$2.run(ServicePool.java:67)
 at org.activeio.xnet.ServicePool$3.run(ServicePool.java:90)
 at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:172)
 at 
 org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(Th
 readPool.java:289)
 at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown 
 So
 urce)
 at java.lang.Thread.run(Unknown Source)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2296) java.lang.ClassNotFoundException org.tranql.ql.QueryException coming on invoking CMP

 [ http://issues.apache.org/jira/browse/GERONIMO-2296?page=all ]

Manu T George updated GERONIMO-2296:


Affects Version/s: 1.1.x
   (was: 1.1)

 java.lang.ClassNotFoundException org.tranql.ql.QueryException coming on 
 invoking CMP
 

 Key: GERONIMO-2296
 URL: http://issues.apache.org/jira/browse/GERONIMO-2296
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: OpenEJB
Affects Versions: 1.1.x
 Environment: All Platforms
Reporter: Manu T George

 When I Invoke a CMP Ejb from a remote client with the corressponding database 
 table dropped. Then I get a ClassNotFoundException wrapped as a 
 RemoteException.  
 java.rmi.RemoteException: Cannot read the response from the server.  The 
 class f
 or an object being returned is not located in this system:; nested exception 
 is:
 java.lang.ClassNotFoundException: org.tranql.ql.QueryException
 at org.openejb.client.Client.request(Client.java:210)
 at 
 org.openejb.client.EJBInvocationHandler.request(EJBInvocationHandler.
 java:212)
 at org.openejb.client.EJBHomeHandler.create(EJBHomeHandler.java:225)
 at org.openejb.client.EJBHomeHandler._invoke(EJBHomeHandler.java:148)
 at 
 org.openejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.j
 ava:183)
 at 
 org.openejb.client.CgLibInvocationHandler.invoke(CgLibInvocationHandl
 er.java:77)
 at 
 org.openejb.client.CgLibInvocationHandler.intercept(CgLibInvocationHa
 ndler.java:67)
 at 
 org.openejb.client.CgLibProxy$$EnhancerByCGLIB$$274269a7.create(gene
 rated)
 at examples.cmp.ProductClient.main(ProductClient.java:34)
 Caused by: java.lang.ClassNotFoundException: org.tranql.ql.QueryException
 at java.net.URLClassLoader$1.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.net.URLClassLoader.findClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClass(Unknown Source)
 at java.lang.ClassLoader.loadClassInternal(Unknown Source)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Unknown Source)
 at java.io.ObjectInputStream.resolveClass(Unknown Source)
 at 
 org.openejb.server.ejbd.EJBObjectInputStream.resolveClass(EJBObjectIn
 putStream.java:84)
 at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
 at java.io.ObjectInputStream.readClassDesc(Unknown Source)
 at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
 at java.io.ObjectInputStream.readObject0(Unknown Source)
 at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
 at java.io.ObjectInputStream.readSerialData(Unknown Source)
 at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
 at java.io.ObjectInputStream.readObject0(Unknown Source)
 at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
 at java.io.ObjectInputStream.readSerialData(Unknown Source)
 at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
 at java.io.ObjectInputStream.readObject0(Unknown Source)
 at java.io.ObjectInputStream.readObject(Unknown Source)
 at org.openejb.client.EJBResponse.readExternal(EJBResponse.java:152)
 at org.openejb.client.Client.request(Client.java:208)
 ... 8 more
 Instead of this maybe a more relevant exception can be wrapped in the 
 RemoteException which will indicate that the table is not found.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Build failure on branches 1.1.1

2006-08-09 Thread Vamsavardhana Reddy

Build is failing since OpenEJB is looking for geronimo-xxx-1.1.2-SNAPHOT jars .

[jira] Commented: (GERONIMO-2268) Security Realm with more than one LoginModule does not function as expected

2006-08-09 Thread Vamsavardhana Reddy (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2268?page=comments#action_12426866
 ] 

Vamsavardhana Reddy commented on GERONIMO-2268:
---

GERONIMO-2268 is a duplicate of GERONIMO-2294, or is it the otherway round? :o)

 Security Realm with more than one LoginModule does not function as expected
 ---

 Key: GERONIMO-2268
 URL: http://issues.apache.org/jira/browse/GERONIMO-2268
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 1.1, 1.1.1, 1.1.x
 Environment: Win XP, G1.1.1-SNAPSHOT, Tomact
Reporter: Vamsavardhana Reddy
 Fix For: 1.1.x, 1.2


 I have created a security realm consisting two login modules.  I have set the 
 control-flag as REQUIRED on both the login modules.  The second login 
 module is supposed to be invoked whether or not the first one succeeds. But 
 the second login module is not invoked when the first one fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (AMQ-855) Add support for prefetchSize = 0

 [ https://issues.apache.org/activemq/browse/AMQ-855?page=all ]

james strachan resolved AMQ-855.


Resolution: Won't Fix

I still don't see a valid use case for this change. Instead I think these 
issues are more applicable to the problem you are trying to solve...

http://issues.apache.org/activemq/browse/AMQ-122
http://issues.apache.org/activemq/browse/AMQ-850

 Add support for prefetchSize = 0
 

 Key: AMQ-855
 URL: https://issues.apache.org/activemq/browse/AMQ-855
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 4.0, 4.0.1, 4.0.2
 Environment: any
Reporter: Vadim Pesochinskiy
Priority: Critical
 Fix For: 4.2


 This feature would enable to support following test case:
 2 servers are processing 3 submitted jobs with following processing times 10 
 min, 1 min, 1 min. This sequence should finish in 10 minutes as one service 
 will pick up the 10 minutes job, meanwhile the other one should manage the 
 two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute 
 jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes 
 instead of 10.
 This is simplification of the real scenario where I have about 30 consumers 
 submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems:
  Messages are sitting in prefetch buffer are not available to processors, 
 which results in a lot of idle time.
  Order of processing is random. For some reason Job # 20 is processed after 
 Job # 1500. Since senders are synchronously blocked this can result in 
 time-outs.
  Some requests are real-time, i.e. there is a user waiting, so the system 
 cannot wait, so AMQ-850 does not fix this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 3)


+1

On 8/8/06, Hiram Chirino [EMAIL PROTECTED] wrote:

Some NOTICE file issues were found in the 2nd release candidate of the
4.0.2 build.  I have cut and RC 3 of the 4.0.2 build with the fixes
and it's available here:


http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3/maven1/incubator-activemq/distributions/

Maven 1 and Maven 2 repos for this release can be found at:
http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3

Here's the wiki page for the release notes (they should soon get
mirrored to the activemq static website) :
http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+4.0.2+Release

Please vote to approve this release binary

[ ] +1 Release the binary as Apache ActiveMQ  4.0.2
[ ] -1 Veto the release (provide specific comments)

If this vote passes, then we will then ask the Incubator PMC for their
blessing to ship this release officially.

Here's my +1

--
Regards,
Hiram

Blog: http://hiramchirino.com




--

James
---
http://radio.weblogs.com/0112098/

[jira] Closed: (XBEAN-38) XFire initialisation problem with spring 2.0-rc2

 [ http://issues.apache.org/jira/browse/XBEAN-38?page=all ]

james strachan closed XBEAN-38.
---


You have invalid XML. change it to

beans
  service xmlns=http://xfire.codehaus.org/config/1.0;
serviceClasscom.effacy.alm.remote.user.RemoteUserFacade/serviceClass
serviceFactoryjsr181/serviceFactory
  /service
/beans 

 XFire initialisation problem with spring 2.0-rc2
 

 Key: XBEAN-38
 URL: http://issues.apache.org/jira/browse/XBEAN-38
 Project: XBean
  Issue Type: Bug
  Components: spring
Affects Versions: 2.5
 Environment: The following maven dependencies were pulled in:
  o com.sun.xml.bind:jaxb-xjc:jar:2.0.1
  o org.springframework:spring-jpa:jar:2.0-rc2
  o snowball:snowball:jar:1.0.0
  o commons-httpclient:commons-httpclient:jar:3.0
  o org.codehaus.xfire:xfire-aegis:jar:1.1.2
  o asm:asm:jar:1.5.3
  o xmlbeans:xbean:jar:2.1.0
  o org.codehaus.xfire:xfire-xmlbeans:jar:1.1.2
  o xerces:xercesImpl:jar:2.6.2
  o commons-codec:commons-codec:jar:1.3
  o asm:asm-attrs:jar:1.5.3
  o javax.mail:mail:jar:1.4
  o stax:stax-api:jar:1.0
  o org.codehaus.xfire:xfire-annotations:jar:1.1.2
  o org.codehaus.xfire:xfire-spring:jar:1.1.2
  o org.codehaus.xfire:xfire-jaxb2:jar:1.1.2
  o xfire:xfire-jsr181-api:jar:1.0-M1
  o jaxen:jaxen:jar:1.1-beta-9
  o com.sun.xml.bind:jaxb-impl:jar:2.0.1
  o javax.activation:activation:jar:1.1
  o wsdl4j:wsdl4j:jar:1.5.2
  o commons-attributes:commons-attributes-api:jar:2.1
  o qdox:qdox:jar:1.5
  o org.springframework:spring:jar:2.0-rc2
  o org.apache.ws.commons:XmlSchema:jar:1.0.3
  o org.hibernate:hibernate-entitymanager:jar:3.2.0.cr1
  o xerces:xmlParserAPIs:jar:2.6.2
  o stax-utils:stax-utils:jar:snapshot-20040917
  o org.apache.xbean:xbean-spring:jar:2.5
  o org.codehaus.xfire:xfire-java5:jar:1.1.2
  o org.codehaus.xfire:xfire-core:jar:1.1.2
  o javax.xml:jaxb-api:jar:2.0
Reporter: Steve Baker
 Fix For: 2.5


 I have attempted to configure a simple jsr181 web service using XFire and am 
 getting the following stack trace when the web service is accessed.
 I'm assuming the only unusual aspect of my setup is using spring version 
 2.0-rc2.
 !DOCTYPE web-app
 PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN
 http://java.sun.com/dtd/web-app_2_3.dtd;
 web-app
   servlet
 servlet-nameXFire/servlet-name
 display-nameXFire Servlet/display-name
 servlet-class
 org.codehaus.xfire.transport.http.XFireConfigurableServlet
 /servlet-class
 !--
   The servlet will by default look for the configuration on
   the classpath in META-INF/xfire/services.xml. You can
   override it with this parameter. Seperate multiple configuration files 
 with a comma.
  --
 init-param
   param-nameconfig/param-name
   param-valueservices.xml/param-value
 /init-param
   /servlet
   servlet-mapping
 servlet-nameXFire/servlet-name
 url-pattern/servlet/XFireServlet/*/url-pattern
   /servlet-mapping
   servlet-mapping
 servlet-nameXFire/servlet-name
 url-pattern/services/*/url-pattern
   /servlet-mapping
 /web-app
 beans xmlns=http://xfire.codehaus.org/config/1.0;
   service
 serviceClasscom.effacy.alm.remote.user.RemoteUserFacade/serviceClass
 serviceFactoryjsr181/serviceFactory
   /service
 /beans
 [ INFO:XmlBeanDefinitionReader.java:  330] - Loading XML bean 
 definitions from class path resource [org/codehaus/xfire/spring/xfire.xml]
 [ERROR:   XFireServlet.java:   51] - Error initializing 
 XFireServlet.
 org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected 
 exception parsing XML document from class path resource 
 [org/codehaus/xfire/spring/xfire.xml]; nested exception is 
 java.lang.IllegalArgumentException: ClassLoader must not be null
 Caused by: 
 java.lang.IllegalArgumentException: ClassLoader must not be null
   at org.springframework.util.Assert.notNull(Assert.java:113)
   at 
 org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:82)
   at 
 org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:74)
   at 
 org.apache.xbean.spring.context.v2.XBeanNamespaceHandlerResolver.init(XBeanNamespaceHandlerResolver.java:26)
   at 
 org.apache.xbean.spring.context.v2.XBeanXmlBeanDefinitionReader.createDefaultNamespaceHandlerResolver(XBeanXmlBeanDefinitionReader.java:81)
   at

Re: JPA plugin (was Re: Java 1.4 and JEE 5)

2006-08-09 Thread David Blevins

Personally, I'm happy that Aaron still wants to work on Geronimo at  
all.  If he wants to work out on SourceForge, that's really his  
decision no matter what the reasons.  I don't see an upside to  
pushing the topic.


As long as he doesn't get upset that others are working on  
potentially the same thing inside Geronimo, then we're in good shape.


Hey Aaron, I'm going to start a branch tomorrow to experiment with  
JPA stuff, you and your crew are obviously welcome to play in my  
sandbox :)  Regardless, I really like the discussion we're having --  
helps keep me focused and I like comparing notes.


Best case scenario, we end up with some excellent JPA functionality  
for 1.1 and 1.2 as well as plugins for ASL and GPL JPA providers.


These are things users need badly.  Good goals.

-David

On Aug 8, 2006, at 10:34 PM, Kevan Miller wrote:


Aaron,
I didn't disagree with your conclusion. You gave 3 reasons for not  
performing the work at Apache. All you needed was one -- licensing  
issues prevent this work from occurring at Apache. Maybe so, but so  
far only you have made that evaluation. I'm not intimating that you  
are wrong, only that, to my knowledge, it hasn't been discussed...


You gave two additional reasons for not performing the work at  
Apache. I commented on those two reasons. The rest inline...


On Aug 8, 2006, at 5:52 PM, Aaron Mulder wrote:


On 8/8/06, Kevan Miller [EMAIL PROTECTED] wrote:


On Aug 8, 2006, at 3:47 PM, Aaron Mulder wrote:

 On 8/8/06, David Blevins [EMAIL PROTECTED] wrote:
 So who is we and why SourceForge?  I can certainly see having
 Hibernate provider plugins and stuff there, but I definitely  
intend

 on writing the core bits in Geronimo svn.

 we is myself and some folks at Chariot.  At SourceForge  
because 1)
 we need some place to collaborate on the code and that's  
impossible
 under RTC, 2) we are working primarily with TopLink during  
development

 and that's impossible at Apache, 3) it was easier to set up a
 SourceForge project than Codehaus and I don't know what to make of
 Google, and 4) I was explicitly told that plugin development  
should be

 done outside of Apache.

Regarding 1) -- too bad you feel this way.


Well, how would you recommend working on new features with others?
Normally you commit when you're at a point that you want to share and
then others can update.  Under RTC, you have to post to a Jira and
propose a vote and get 3 PMC members on board before anyone else can
update.  So really, it's collaboration via pasting patches to Jira.
That's ridiculous.  The next alternative is a branch.  I've seen Dain
and Jason do the branch thing, and it looked to me like they spent as
much time trying to keep the branch in sync with trunk as actually
working on the branch.  No thanks.  So what do you recommend?  Do
everything in the sandbox?


So, which is it? Do you want the code to come to Geronimo, or not?  
If you do, then I suggest you work with the community in realizing  
that. Communicate your plans, discuss your ideas, and follow the  
community process for contributing code.






Regarding 4) -- that's news to me and I can see no reason why that
would be true.


Please, enlighten me as to how we can work with TopLink and Hibernate
within the context of Geronimo?  Are we allowed to include GPL  
modules

in the build now?  And how do I work with people who have cycles to
contribute but aren't committers?  Are we back to collaboration via
patches on Jira?  Also, how about the fact that Matt and Alan have
remained firmly opposed to new features in the 1.1 branch.  So where
do you recommend we develop JPA for Geronimo 1.1?  Sandbox?


You said 4) I was explicitly told that plugin development should  
be done outside of Apache. This implies that no plugin should ever  
be implemented within Apache. I wasn't questioning the specifics of  
your case, I was questioning the generalities of that statement. I  
can see no reason why it would be true.


I agree with Matt and Alan, but why would a plugin need to be  
within the 1.1 branch? How about geronimo/plugins/app-jpa/trunk? Or  
initially, sandbox/app-jpa/trunk?




Look, you have to admit, it's not realistic for all Geronimo-related
development to be done within the context of Geronimo.  ActiveMQ,
OpenEJB, and TranQL have gone forever as independent projects, Jencks
and WebSphere CE are heavily leveraging Geronimo, LifeRay and Apache
Directory are certainly not developing their stuff at
geronimo.apache.org, I could give 20 examples.


Yes, and World Hunger is a bad thing. I never said that your plugin  
should be developed at Apache. I just questioned some of the  
reasons why you said it *could* not be developed at Apache.




Please list the advantages of developing plugins inside the Geronimo
project.  To me, plugins are best developed elsewhere, and what we
learn developing the plugins should feed ideas for improvements into
the core product, so it can better support a wider variety

[jira] Commented: (AMQ-855) Add support for prefetchSize = 0

[ 
https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36718 ] 

james strachan commented on AMQ-855:


BTW just to be absolutely clear - here's how I think we should fix Vadim's use 
case.

If we had full support for priority based dispatching so that...

* all high priority messages are dispatched before *ANY* medium priority.
* all medium priority messages are dispatched before *ANY* low priority
* all low priority messages are then dispatched

Then the consumers all have a prefetch of 1 and each consumer subscribes to 
high, medium and low priority messages.

The reason I don't see the prefetch of zero fixing the issue is as follows..

imagine the client did this...

message = highConsumer.receive(timeout);
if (message == null) {
   // a high message could have just arrived now...
   message = mediumConsumer.receive(timeout);
   // a high message could have just arrived now...
}
if (message == null) {
   // a high message could have just arrived now...
   message = lowConsumer.receive(timeout);
   // a high message could have just arrived now...
}
// a high message could have just arrived now...


there's still a chance the client would miss the high priority messages 
arriving as they will spend a reasonable amount of time in wait loops waiting 
to request-response to the broker.

The only way to truly guarrentee ordering is to get the broker to do it.

 Add support for prefetchSize = 0
 

 Key: AMQ-855
 URL: https://issues.apache.org/activemq/browse/AMQ-855
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 4.0, 4.0.1, 4.0.2
 Environment: any
Reporter: Vadim Pesochinskiy
Priority: Critical
 Fix For: 4.2


 This feature would enable to support following test case:
 2 servers are processing 3 submitted jobs with following processing times 10 
 min, 1 min, 1 min. This sequence should finish in 10 minutes as one service 
 will pick up the 10 minutes job, meanwhile the other one should manage the 
 two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute 
 jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes 
 instead of 10.
 This is simplification of the real scenario where I have about 30 consumers 
 submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems:
  Messages are sitting in prefetch buffer are not available to processors, 
 which results in a lot of idle time.
  Order of processing is random. For some reason Job # 20 is processed after 
 Job # 1500. Since senders are synchronously blocked this can result in 
 time-outs.
  Some requests are real-time, i.e. there is a user waiting, so the system 
 cannot wait, so AMQ-850 does not fix this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (AMQ-770) consumer.dispatchAsync defaults to false

 [ https://issues.apache.org/activemq/browse/AMQ-770?page=all ]

james strachan resolved AMQ-770.


Fix Version/s: 4.1
   Resolution: Fixed

This was a documentation error. We default to false to minimise the number of 
threads used by default.

http://activemq.org/site/destination-options.html

It would be nice to be able to overload things like this on the broker side 
maybe

 consumer.dispatchAsync defaults to false
 

 Key: AMQ-770
 URL: https://issues.apache.org/activemq/browse/AMQ-770
 Project: ActiveMQ
  Issue Type: Bug
  Components: JMS client
Affects Versions: 4.0, 4.0.1
Reporter: Kevin Yaussy
Priority: Minor
 Fix For: 4.1


 Seems like there was a change between 4.0-RC3 and incubator-4.0(.1) with 
 regards to the default value for the destination option 
 consumer.dispatchAsync.  According to the web documentation for destination 
 options, as well as behavior in RC3, the default is true.  However, it looks 
 like incubator-4.0(.1) defaults to false.  I have to explicitly give the 
 consumer.dispatchAsync=true for a destination option, in order to get async 
 dispatch in the Broker.
 Is this a code bug, or documentation bug?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Start JavaMail by default in 1.1.1?


Aaron Mulder wrote:

I don't see a great reason that we're not starting the JavaMail module
by default.  Granted, the user may need to change the SMTP server, but
it's going to be easier if they don't need to enable the module too
(e.g. the console usually doesn't see disabled GBeans, and the
load=false is easy enough to miss in config.xml).
I think this is probably a good idea.  Most of the problems I've seen 
with users attempting to use javamail have been caused by the fact the 
javamail module has not been started.  This usually manifests as a 
provider resolution failure because the transport jars are not showing 
up in the classpath.  Because the spec jars ARE there by default, this 
error doesn't show up until it is used.





What do you think?

Thanks,
Aaron

[jira] Created: (SM-525) Enhancement to ValidateComponent to implement a complete and flexible error handling scheme for schema validation

2006-08-09 Thread Grant McDonald (JIRA)

Enhancement to ValidateComponent to implement a complete and flexible error 
handling scheme for schema validation
-

 Key: SM-525
 URL: https://issues.apache.org/activemq/browse/SM-525
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-components
 Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD
Reporter: Grant McDonald
 Attachments: servicemix-components.zip

The purpose of this enchancement was to provide the following:

1) Allow error messages to be captured by the ValidateComponent and sent back 
as the content of a fault message;
2) Preserve existing functionality; and
3) Provide a framework for extending the functionality

It was noted that the existing functionality only dealt with simple case valid 
or not valid schemas.  It was decided to make the standard component more 
extensible and functional and as such this code is being contributed back to 
the ServiceMix project.  To this end the following changes have been made and 
are available in the attached zip file:

1) Added MessageAwareErrorHandler interface - this interface extends the 
org.xml.sax.ErrorHandler interface and adds contracts for determining if the 
error handler has errors, whether it captures messages from the validator, and 
what message formats it supports.

2) Refactored CountingErrorHandler to extend from MessageAwareErrorHandler and 
implement the above mentioned methods

3) Created MessageAggregatingErrorHandler - this class aggregates all warning, 
error and fatal error messages into an XML format (via CDATA).  It provides the 
ability to set the root document path and namespace via configuration and 
supports DOMSource, StringSource and String formats for the encapsulated data.

4) modified ValidateComponent - added errorHandler property to facilitate 
dependency injection, with a default value of CountingErrorHandler to preserve 
existing functionality.  Refactored the handling of validation errors to use 
the new interfaces.  errorHandlers which do not support the capturing of 
messages will use the previous method of sending the DOMResult back as the 
fault message content.  errorHandlers which do support the capture of messages 
will send the error message xml back as the fault message content.  The src 
document is now set as a property on the fault message.

Additionally, a null pointer check was added to the init on the 
schemaResource.getURL() method call.

A testcase has been added to ValidationTest and the example.xml in the 
validation test/resources package demonstrates the configuration of this 
functionality.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (SM-526) Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL

2006-08-09 Thread Grant McDonald (JIRA)

Fault messages returned to BPEL via servicemix-bpe are not accessible in BPEL
-

 Key: SM-526
 URL: https://issues.apache.org/activemq/browse/SM-526
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-bpe
 Environment: Ubuntu Linux 5.10, Windows XP SP2, ServiceMix HEAD
Reporter: Grant McDonald
 Attachments: servicemix-bpe.zip

When returning output and fault messages an XMLInteractionObject is currently 
being used to wrap the Document object created from the NormalizedMessage.  The 
use of XMLInteractionObject is deprecated within ODE and due to some not 
entirely   understood code paths this results in Fault messages being wrapped 
in a CannedFormattableValue which renders the object immutable in BPEL and its 
data unretrieveable to the JBI world when sent back to ServiceMix.

The answer is to use instead DescribedValue from ODE/BPE to wrap both the 
output and fault messages of a JBI invoke action.  A patch for this has been 
attached.  Testing has been done, although no test cases have been prepared.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (AMQ-871) Allow MessageEvictionStrategy to evict more than one MessageReference in evictMessage(LinkedList message) method

 [ https://issues.apache.org/activemq/browse/AMQ-871?page=all ]

james strachan resolved AMQ-871.


Fix Version/s: 4.1
   Resolution: Fixed
 Assignee: james strachan

Patch applied with thanks!

Incidentally for bad eviction strategies which do not return any messages to 
evict - I modified the patch to log a warning of the badly behaving eviction 
strategy - then we just don't evict anything. 

I guess its OK to now and again decide not to evict anything (so maybe we 
should only log a warning the first time or something) - though really if you 
set a high watermark of a number of messages per consumer we really should be 
evicting messages so I guess a warning is the best solution so far.

 Allow MessageEvictionStrategy to evict more than one MessageReference in 
 evictMessage(LinkedList message) method
 

 Key: AMQ-871
 URL: https://issues.apache.org/activemq/browse/AMQ-871
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Reporter: Mathew Kuppe
 Assigned To: james strachan
 Fix For: 4.1

 Attachments: evictMultipleMessages-patch.txt


 For slow consumers every time a single message is added to a 
 TopicSubscription where the pending message limit is reached, a new call to 
 evictMessage is made. To allow for more flexible and efficient means of 
 evicting messages it would be nice to be able to evict multiple messages in 
 one call to evictMessage. This allows new MessageEvictionStrategy 
 implementations to evict based on age of messages (eg. evict all messages in 
 the pending message list that are older than x ms), duplicate messages (evict 
 all messages that are redundant based on newer messages currently in the 
 pending message list) etc. As a single call to the evictMessage method may 
 have the opportunity to reduce the size of the pending message list by more 
 than one it means that the next message added to the TopicSubscription may 
 not need to have to call the evictMessage again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (GERONIMODEVTOOLS-97) Need to remove jetty and tomcat server dependency in assembly\pom.xml to build devtools.

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-97?page=all ]

Sachin Patel reassigned GERONIMODEVTOOLS-97:


Assignee: Sachin Patel

 Need to remove jetty and tomcat server dependency in assembly\pom.xml to 
 build devtools.
 

 Key: GERONIMODEVTOOLS-97
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-97
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.1.0
 Environment: WinXP + SUN 1.4.2
Reporter: Lin Sun
 Assigned To: Sachin Patel
Priority: Minor
 Attachments: devtools97.patch


 With the latest devtools 93 change, it is necessary to remove the jetty and 
 tomcat server dependency in assembly\pom.xml.   otherwise, devtools won't be 
 able to build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMODEVTOOLS-97) Need to remove jetty and tomcat server dependency in assembly\pom.xml to build devtools.

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-97?page=all ]

Sachin Patel closed GERONIMODEVTOOLS-97.


Resolution: Fixed

 Need to remove jetty and tomcat server dependency in assembly\pom.xml to 
 build devtools.
 

 Key: GERONIMODEVTOOLS-97
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-97
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.1.0
 Environment: WinXP + SUN 1.4.2
Reporter: Lin Sun
 Assigned To: Sachin Patel
Priority: Minor
 Attachments: devtools97.patch


 With the latest devtools 93 change, it is necessary to remove the jetty and 
 tomcat server dependency in assembly\pom.xml.   otherwise, devtools won't be 
 able to build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMODEVTOOLS-96) Has to add xmlbeans as dependency in pom.xml to build devtools

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-96?page=all ]

Sachin Patel closed GERONIMODEVTOOLS-96.


Resolution: Fixed
  Assignee: Sachin Patel

 Has to add xmlbeans as dependency in pom.xml to build devtools
 --

 Key: GERONIMODEVTOOLS-96
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-96
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.1.0
 Environment: WinXP + SUN JRE 1.4.2
Reporter: Lin Sun
 Assigned To: Sachin Patel
 Attachments: devtools96.patch


 The new devtools change (devtools 94) uses classes from xmlbeans, however, 
 the pom.xml isn't updated to reflect that yet.  I had to add xmlbeans as a 
 dependency in my plugins\org.apache.geronimo.st.core\pom.xml to build 
 devtools successfully.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-90) Deployment errors all on one line

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-90?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-90:
-

Fix Version/s: 1.x

 Deployment errors all on one line
 -

 Key: GERONIMODEVTOOLS-90
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-90
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
 Environment: Windows, Eclipse Callisto, Geronimo Eclipse Plugin 1.1 
 RC3
Reporter: Neal Sanche
 Fix For: 1.x


 Whenever there is a deployment error, the stacktrace of the error is 
 displayed all on one line. I don't know why that would be, perhaps it is 
 being formatted with UNIX end of line characters instead of DOS \r\n? Anyway, 
 it would be nice if this error message were displayed properly. Perhaps the 
 Message property of the exception, and any inner exceptions could be 
 displayed, followed by the stacktrace?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-91) WTP server adapters for geronimo needs to provide extensibility, like an OEM vendor.

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-91?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-91:
-

Fix Version/s: 1.x

 WTP server adapters for geronimo needs to provide extensibility, like an OEM 
 vendor.
 

 Key: GERONIMODEVTOOLS-91
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-91
 Project: Geronimo-Devtools
  Issue Type: New Feature
  Components: eclipse-plugin
Affects Versions: 1.1.0
 Environment: all environments
Reporter: Lin Sun
 Fix For: 1.x


 The WTP server adapter for geronimo, also known as devtools project, needs to 
 provide extensibility, like an OEM vendor so that other companies can build 
 their additional plugins to brand Apache Geronimo to their companies' logo or 
 name, with AG's eclipse plugins untouched.One example is that Eclipse 
 allow other vendors to brand Eclipse, for example, you could configure a 
 different splash screen.
 There are two things I see here, and there can be others that I am missing:
 1) There is a geronimo-1.1 appended to the installation path after user 
 clicks on the Download and Install button to download either the jetty or 
 tomcat distribution.   This is undesired.   
 2) There are two buttons (Jetty or Tomcat).  It should be configurable as 
 other companies may want to distribute jetty only, tomcat only or both.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-73) Geronimo needs to support IModulePublishHelper.getPublishDirectory() to get to the server's publish directory

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-73?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-73:
-

Fix Version/s: 1.x

 Geronimo needs to support IModulePublishHelper.getPublishDirectory() to get 
 to the server's publish directory
 -

 Key: GERONIMODEVTOOLS-73
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-73
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.0.0
 Environment: WTP 1.0.1 + Geronimo 1.0 plugin + Geronimo 1.0 server
Reporter: Kathy Chan
 Assigned To: Sachin Patel
 Fix For: 1.x


 After creating a Web service using the Web service wizard on a Web project 
 targetting Geronimo server, the file server-config.wsdd is generated in the 
 server installation config-store directory under WAR name/WEB-INF.  
 However, if I change something in the EAR and republish, the 
 server-config.wsdd file is gone.  Note that the server-config.wsdd file is 
 not in the workspace. 
 I am relying on the IModulePublishHelper.getPublishDirectory() API in the 
 org.eclipse.wst.server.core plugin to get the server's publish directory in 
 order to copy the server-config.wsdd file into the workspace so that next 
 time the WAR/EAR is re-published, the information of what was deployed to the 
 Axis servlet is persisted.
 Tomcat is currently implementing that and Geronimo needs to implement 
 IModulePublishHelper.getPublishDirectory() as well.
 Here's the current implementation in TomcatBehaviour.getPublishDirectory():
 /**
* Returns the path that the module is
* published to when in test environment mode.
* 
* @param module a module on the server 
* @return the path that the module is published to when in test 
 environment mode,
*or null if not running as a test environment or the module is not 
 a web module
*/
   public IPath getPublishDirectory(IModule[] module) {
   if (!getTomcatServer().isTestEnvironment() || module == null || 
 module.length != 1)
   return null;
   
   return 
 getTempDirectory().append(webapps).append(module[0].getName());
   }
 This solution would solve the problem for getting to server-config.wsdd for 
 Axis Web service but there is still a bigger general problem with files 
 created in the config-store directory not mirrored in the workspace.  
 Hopefully this will be addressed in the next release of the Geronimo plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-86) Stack Traces upon Publishing Errors are difficult to read

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-86?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-86:
-

Fix Version/s: 1.x

 Stack Traces upon Publishing Errors are difficult to read
 -

 Key: GERONIMODEVTOOLS-86
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-86
 Project: Geronimo-Devtools
  Issue Type: Improvement
  Components: eclipse-plugin
 Environment: Windows, Eclipse Callisto RC4a.
Reporter: Neal Sanche
 Fix For: 1.x


 The stack traces produced when the eclipse plugin fails to deploy a project 
 to the server appear all on one line, so that the developer has to scroll 
 horizontally to find the cause of the problem. An improvement I would suggest 
 would be to present the user the Message text of the exception and all of the 
 CausedBy exceptions first, then rewrite the stacktrace to provide the correct 
 line-breaks for the platform before displaying it to the user.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-92) Support builds on Linux x86_64 based systems

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-92?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-92:
-

Fix Version/s: 1.x

 Support builds on Linux x86_64 based systems
 

 Key: GERONIMODEVTOOLS-92
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-92
 Project: Geronimo-Devtools
  Issue Type: Improvement
  Components: eclipse-plugin
Affects Versions: 1.1.0
 Environment: SLES 10 on x86_64
Reporter: Donald Woods
 Assigned To: Donald Woods
Priority: Minor
 Fix For: 1.x


 Need to update the maven-geronimodevtools-plugin to support more than just 
 Windows x86, Linux x86 and MacOS.
 Will test and provide a patch tomorrow that allows builds on x86_64 Linux 
 systems (like SLES10 on Intel EM64T or AMD64).
 Will also include code to recognize Linux on ppc, AIX on ppc, SunOS on x86 
 and SunOS on sparc, but will not be able to verify all those systems (just 
 going by the os.arch and org.eclipse.swt.* mappings.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-57) When user configure server and put wrong password, no message is shown

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-57?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-57:
-

Fix Version/s: 1.x

 When user configure server and put wrong password, no message is shown
 --

 Key: GERONIMODEVTOOLS-57
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-57
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
 Environment: Win2K, Sun JDK 1.4.2, Eclipse 3.11 with WTP 1.0.1 and 
 latest daily build of eclipse plugin (20060130-0958)
Reporter: Edson Richter
 Fix For: 1.x


 When developer configure a new server, it should select HTTP Port, RMI Port 
 and administration user and password. If user and/or password is wrong, when 
 Geronimo is started by developer, no message is shown about wrong user or 
 password, and status for server stay on starting forever (or, at least, 
 until timeout occur).
 Expected behaviour is if user or password is incorrect, a message is shown so 
 developer could correct this in server properties.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-65) Support qualifer builds

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-65?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-65:
-

Fix Version/s: 1.x

 Support qualifer builds
 ---

 Key: GERONIMODEVTOOLS-65
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-65
 Project: Geronimo-Devtools
  Issue Type: Task
  Components: eclipse-plugin
Reporter: Sachin Patel
 Fix For: 1.x


 Support  qualifiers in plugins and features.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-75) DEBUG messages are shown when INFO was selected.

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-75?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-75:
-

Fix Version/s: 1.x

 DEBUG messages are shown when INFO was selected.
 

 Key: GERONIMODEVTOOLS-75
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-75
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.0.0
Reporter: Archimedes Trajano
 Fix For: 1.x


 DEBUG messages are shown in the console, although I only had INFO selected in 
 Console Output

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-40) Cannot start server programmatically

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-40?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-40:
-

Fix Version/s: 1.x

 Cannot start server programmatically
 

 Key: GERONIMODEVTOOLS-40
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-40
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
 Environment: Windows XP
Reporter: Kathy Chan
 Assigned To: Sachin Patel
Priority: Critical
 Fix For: 1.x


 I was using the following drivers on Windows XP:
 - WTP 1.0
 - Geronimo 1.0 server 
 - Geronimo 20060109 plugin
 With a new workspace, do the following:
 - install Geronimo 1.0 server runtime
 - create Geronimo server using server tooling
 - start server
 - create Web project a1 with EAR
 - In the Web project, create a simple Echo.java with a hello method that 
 takes a String and returns it.
 Here are the procedure to create a bottom-up Web service:
 - right-click on Echo.java, select Web Services - Create Web service
 - select test Web service and overwrite file on the 1st page of Web 
 service wizard
 - click Finish
 - when the Web Services Explorer comes up, you should be able to invoke the 
 hello method
 Now, if you remove the Web project a1 from the server and ensure that the 
 server is still in started state, then you can repeat the above steps to 
 create a bottom-up Web service.  
 However, if you do not remove the Web project from the server first, then 
 you'll run into the problem reported in bug 
 http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-39.
 If you remove the Web project from the server first but stop the server 
 before creating the bottom-up Web service, when the Web service wizard tried 
 to start the server programmatically, you'll notice that the server console 
 indicates that 
 Geronimo startup complete
 but server tooling still thinks that the server is started.  The server start 
 will eventually times out.
 Now, even if I use server tooling to start the server, server start would not 
 complete.  This problem persist even if I delete the server and recreate 
 another one.  The only way I could recover is to use a new workspace.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-76) Geronimo Fails if deploying a 'Bottom Up Web Service'

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-76?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-76:
-

Fix Version/s: 1.x

 Geronimo Fails if deploying a 'Bottom Up Web Service'
 -

 Key: GERONIMODEVTOOLS-76
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-76
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.0.0
 Environment: Eclipse 3.1.1 (Build: M20050929-0840)
 WTP: 1.0.1.v2006
 Geronimo: 1.0 with Jetty
 Eclipse command: eclipse
 Java SE Version: j2sdk1.4.2_10
 OS: Windows 2k and Windows XP
Reporter: Daniel S. Haischt
 Fix For: 1.x

 Attachments: geronimo-axis-err.7z


 Today I tried several times to deploy a web service according to the tutorial 
 at...
 http://www.eclipse.org/webtools/community/tutorials/BottomUpWebService/BottomUpWebService.html
 ... Each time I am getting the following error message:
 IWAB0489E Error when deploying Web service to Axis runtime
   axis-admin failed with  {http://xml.apache.org/axis/}HTTP (404)Not Found
 This is a fresh Eclipse/WTP install.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-87) Distribution of configuration failed

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-87?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-87:
-

Fix Version/s: 1.x

 Distribution of configuration failed
 

 Key: GERONIMODEVTOOLS-87
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-87
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.0.0
 Environment: eclipse.buildId=M20060629-1905
 java.version=1.4.2_10
 java.vendor=Sun Microsystems Inc.
 BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=fr_BE
 Command-line arguments:  -os win32 -ws win32 -arch x86
 WPT 1.5 (Callisto)
 Geronimo 1.0
Reporter: Jens Nicolay
 Fix For: 1.x


 When I do the following...
 - create Dynamic Web Project, name: TestWeb
 - create Servlet in TestWeb, name: TestServlet
 - TestServlet.java - Run on Server - Geronimo
 ... I get this error:
 Error
 Mon Jul 03 11:42:51 CEST 2006
 Distribution of configuration failed.  See .log for details.
 java.lang.Exception: Cannot deploy the requested application module 
 (moduleFile=C:\DOCUME~1\ADSL\LOCALS~1\Temp\geronimo-deployer12834.tmpdir\TestWeb.zip)
 org.apache.geronimo.common.DeploymentException: Cannot deploy the requested 
 application module 
 (moduleFile=C:\DOCUME~1\ADSL\LOCALS~1\Temp\geronimo-deployer12834.tmpdir\TestWeb.zip)
   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:226)
   at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102)
   at 
 org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated)
   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
   at 
 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
   at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
   at 
 org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
   at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125)
   at 
 org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated)
   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
   at 
 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
   at 
 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835)
   at 
 org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178)
   at 
 org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117)
   at 
 mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219)
   at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34)
   at 
 mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99)
   at 
 mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSubjectInvoker.java:31)
   at 
 mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjectInvoker.java:90)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.Subject.doAsPrivileged(Unknown Source)
   at mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:163)
   at 
 mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(RMIConnectionSubjectInvoker.java:86)
   at 
 mx4j.remote.rmi.RMIConnectionSubjectInvoker.invoke(RMIConnectionSubjectInvoker.java:80)
   at $Proxy0.invoke(Unknown Source)
   at 
 javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:221)
   at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
   at sun.rmi.transport.Transport$1.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at sun.rmi.transport.Transport.serviceCall(Unknown Source)
   at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
   at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown 
 Source)
   at java.lang.Thread.run(Unknown Source)
   at 
 org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:329)
   at 
 org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:260)

[jira] Updated: (GERONIMODEVTOOLS-95) pim.xml still uses WTP 1.5.0

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-95?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-95:
-

Fix Version/s: 1.x

 pim.xml still uses WTP 1.5.0
 

 Key: GERONIMODEVTOOLS-95
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-95
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.1.0
Reporter: Lin Sun
Priority: Minor
 Fix For: 1.x


 The pom.xml at the root dir still uses:
 
 wtpUrlhttp://download.eclipse.org/webtools/downloads/drops/R1.5/R-1.5.0-200606281455/wtp-sdk-R-1.5.0-200606281455.zip/wtpUrl
 It should move to WTP 1.5.1 build ( for example: 
 wtp-sdk-M-1.5.1-200608032139.zip), as WTP 1.5.1 is required for certain 
 functions (devtools 93) checked in lately.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-71) Geronimo publish failed with javax.naming.NoInitialContextException

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-71?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-71:
-

Fix Version/s: 1.x

 Geronimo publish failed with javax.naming.NoInitialContextException
 ---

 Key: GERONIMODEVTOOLS-71
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-71
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
 Environment: WTP 1.0.1 + Geronimo 1.0 plugin + Geronimo 1.0 server
 Starting Eclipse with IBM JRE 1.4.2 J2RE 1.4.2 IBM Windows 32 build 
 cn142-20050609
Reporter: Kathy Chan
 Fix For: 1.x


 I had an EAR that's deployed to a Geronimo server.  After I changed a Java 
 file and re-publish to the server using server tooling popup menu on the 
 server, I got the Publish Failed error.  Here's the application console log:
 !SUBENTRY 1 org.apache.geronimo.devtools.eclipse.core 4 0 2006-03-07 
 13:08:59.630
 !MESSAGE Connection to deployment manager failed.  See .log for details.
 !STACK 0
 javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: 
 javax.naming.NoInitialCon
 textException: Cannot instantiate class: 
 org.apache.naming.java.javaURLContextFactory [Root exceptio
 n is java.lang.ClassNotFoundException: 
 org.apache.naming.java.javaURLContextFactory]
 at 
 org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManage
 r(DeploymentFactoryImpl.java:132)
 at 
 javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(De
 ploymentFactoryManager.java:109)
 at 
 org.apache.geronimo.core.GeronimoConnectionFactory.getDeploymentManager(GeronimoConnectio
 nFactory.java:54)
 at 
 org.apache.geronimo.core.commands.DeploymentCommandFactory.getDeploymentManager(Deploymen
 tCommandFactory.java:111)
 at 
 org.apache.geronimo.core.commands.DeploymentCommandFactory.createRedeployCommand(Deployme
 ntCommandFactory.java:87)
 at 
 org.apache.geronimo.core.internal.GeronimoServerBehaviour.reDeploy(GeronimoServerBehaviou
 r.java:361)
 at 
 org.apache.geronimo.core.internal.GeronimoServerBehaviour.doRedeploy(GeronimoServerBehavi
 our.java:282)
 at 
 org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBeh
 aviour.java:234)
 at 
 org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBeh
 aviour.java:217)
 at 
 org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDe
 legate.java:672)
 at 
 org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourD
 elegate.java:752)
 at 
 org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate
 .java:610)
 at 
 org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:800)
 at 
 org.eclipse.wst.server.core.internal.Server.publish(Server.java:788)
 at 
 org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145)
 at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
 Caused by: java.io.IOException: javax.naming.NoInitialContextException: 
 Cannot instantiate class: or
 g.apache.naming.java.javaURLContextFactory [Root exception is 
 java.lang.ClassNotFoundException: org.
 apache.naming.java.javaURLContextFactory]
 at 
 mx4j.remote.resolver.rmi.Resolver.lookupStubInJNDI(Resolver.java:100)
 at 
 mx4j.remote.resolver.rmi.Resolver.lookupRMIServerStub(Resolver.java:72)
 at mx4j.remote.resolver.rmi.Resolver.lookupClient(Resolver.java:52)
 at 
 javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:119)
 at 
 javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:38)
 at 
 org.apache.geronimo.deployment.plugin.factories.DeploymentFactoryImpl.getDeploymentManage
 r(DeploymentFactoryImpl.java:125)
 at 
 javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(De
 ploymentFactoryManager.java:109)
 at 
 org.apache.geronimo.core.GeronimoConnectionFactory.getDeploymentManager(GeronimoConnectio
 nFactory.java:54)
 at 
 org.apache.geronimo.core.commands.DeploymentCommandFactory.getDeploymentManager(Deploymen
 tCommandFactory.java:111)
 at 
 org.apache.geronimo.core.commands.DeploymentCommandFactory.createRedeployCommand(Deployme
 ntCommandFactory.java:87)
 at 
 org.apache.geronimo.core.internal.GeronimoServerBehaviour.reDeploy(GeronimoServerBehaviou
 r.java:361)
 at 
 org.apache.geronimo.core.internal.GeronimoServerBehaviour.doRedeploy(GeronimoServerBehavi
 our.java:282)
 at 
 org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBeh

[jira] Updated: (GERONIMODEVTOOLS-67) M2 plugin to generate WTP adopter API usage report

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-67?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-67:
-

Fix Version/s: 1.x

 M2 plugin to generate WTP adopter API usage report
 --

 Key: GERONIMODEVTOOLS-67
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-67
 Project: Geronimo-Devtools
  Issue Type: Task
  Components: eclipse-plugin
Reporter: Sachin Patel
 Fix For: 1.x




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-42) Use gzipped archives on Unice

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-42?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-42:
-

Fix Version/s: 1.x

 Use gzipped archives on Unice
 -

 Key: GERONIMODEVTOOLS-42
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-42
 Project: Geronimo-Devtools
  Issue Type: Improvement
  Components: eclipse-plugin
 Environment: Environment: Eclipse: 3.1.1 (Build ID: M20050929-0840)
 Java 2 SE: 1.4.2_10-b03
 OS: Linux ubuntu-abysssix 2.6.12-10-686-smp
Reporter: Daniel S. Haischt
Priority: Trivial
 Fix For: 1.x


 Would it be possible to use a gzipped archive on a Unice OS? I for instance 
 did download geronimo-jetty.(tgz|tar.gz). Unfortunatly maven searches for a 
 ZIP and tries to download it because it is non-existant.
 +
 | Executing jar:install org.apache.geronimo.j2ee.server.v1
 | Memory: 8M/11M
 +
 DEPRECATED: the default goal should be specified in the build section of 
 project.xml instead of maven.xml
 DEPRECATED: the default goal should be specified in the build section of 
 project.xml instead of maven.xml
 build:end:
 build:start:
 java:prepare-filesystem:
 java:compile:
 [echo] Compiling to 
 /home/haischt/geronimo-eclipse-tools/plugins/org.apache.geronimo.j2ee.server.v1/target/classes
 [echo] No java source files to compile.
 java:jar-resources:
 getzip:
 [get] Getting: 
 http://www.apache.org/dist/geronimo/1.0/geronimo-jetty-j2ee-1.0.zip
 [get] To: 
 /home/haischt/.maven/repository/geronimo/distributions/geronimo-jetty-j2ee-1.0.zip

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMODEVTOOLS-35) Plugin: There are two generic servers at Run as--Run... view

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-35?page=all ]

Sachin Patel updated GERONIMODEVTOOLS-35:
-

Fix Version/s: 1.x

 Plugin:  There are two generic servers at Run as--Run... view
 -

 Key: GERONIMODEVTOOLS-35
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-35
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
 Environment: WinXP, JDK 1.4.2, Plugin I built a few days ago, Eclipse 
 3.1.1.
Reporter: Lin Sun
Priority: Minor
 Fix For: 1.x


 If I right click the hello program, and select Run as--Run..., the run 
 configuration screen has two generic servers there like below:
 Apache Tomcat
 Eclipse Application
 Generic Server
  --Apache Geronimo 1.0
 Generic Server
 The second generic server should be removed.  Also, is there a reason why 
 Apache Geronimo is under Generic Server, while Apache Tomcat is not?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Accessing the openejb code?

I just got back from a 2 week vacation and am trying to get caught back 
up again.  When I do a maven m:update on my working build from 2 weeks 
ago, I'm getting the following message followed by a hang:


m:update:
   [exec] At revision 430039.
   [exec] Authentication realm: https://svn.codehaus.org:443 openejb Repo

I get similar behavior when I checkout out a fresh build and do a maven 
m:fresh-checkout.  Is this a glitch with the codehaus svn or should I 
be using something else now to access a build?


Rick

[jira] Closed: (GERONIMODEVTOOLS-73) Geronimo needs to support IModulePublishHelper.getPublishDirectory() to get to the server's publish directory

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-73?page=all ]

Sachin Patel closed GERONIMODEVTOOLS-73.


Resolution: Fixed

 Geronimo needs to support IModulePublishHelper.getPublishDirectory() to get 
 to the server's publish directory
 -

 Key: GERONIMODEVTOOLS-73
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-73
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 1.0.0
 Environment: WTP 1.0.1 + Geronimo 1.0 plugin + Geronimo 1.0 server
Reporter: Kathy Chan
 Assigned To: Sachin Patel
 Fix For: 1.x


 After creating a Web service using the Web service wizard on a Web project 
 targetting Geronimo server, the file server-config.wsdd is generated in the 
 server installation config-store directory under WAR name/WEB-INF.  
 However, if I change something in the EAR and republish, the 
 server-config.wsdd file is gone.  Note that the server-config.wsdd file is 
 not in the workspace. 
 I am relying on the IModulePublishHelper.getPublishDirectory() API in the 
 org.eclipse.wst.server.core plugin to get the server's publish directory in 
 order to copy the server-config.wsdd file into the workspace so that next 
 time the WAR/EAR is re-published, the information of what was deployed to the 
 Axis servlet is persisted.
 Tomcat is currently implementing that and Geronimo needs to implement 
 IModulePublishHelper.getPublishDirectory() as well.
 Here's the current implementation in TomcatBehaviour.getPublishDirectory():
 /**
* Returns the path that the module is
* published to when in test environment mode.
* 
* @param module a module on the server 
* @return the path that the module is published to when in test 
 environment mode,
*or null if not running as a test environment or the module is not 
 a web module
*/
   public IPath getPublishDirectory(IModule[] module) {
   if (!getTomcatServer().isTestEnvironment() || module == null || 
 module.length != 1)
   return null;
   
   return 
 getTempDirectory().append(webapps).append(module[0].getName());
   }
 This solution would solve the problem for getting to server-config.wsdd for 
 Axis Web service but there is still a bigger general problem with files 
 created in the config-store directory not mirrored in the workspace.  
 Hopefully this will be addressed in the next release of the Geronimo plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Java Service Wrapper or Commons Daemon?


I've never used commons-daemon, but JSW is very cool and
works nicely.  Is there any specific features not covered by JSW
that we would need ?

On 8/9/06, James Strachan [EMAIL PROTECTED] wrote:


Anyone have any experience of these 2 solutions to know which one is
the best to use when creating a windows/unix service?

http://wrapper.tanukisoftware.org/doc/english/introduction.html
http://jakarta.apache.org/commons/daemon/index.html

It'd be nice to have a service for ActiveMQ - am just not sure which
one we should use.

Clearly the latter is also hosted at Apache so we're more likely to be
able to patch it if it has issues. The latter is also used by Tomcat
so is very well used.

Anyone used both before who could offer feedback?

--

James
---
http://radio.weblogs.com/0112098/





--
Cheers,
Guillaume Nodet

Re: Accessing the openejb code?

2006-08-09 Thread John Sisson

It appears https access for OpenEJB non-committers isn't available any 
more.  AFAIK the maven build scripts have been updated to take this into 
account, but to be able to use them you will need to do an svn update 
manually, delete the openejb directory and then try a  maven 
m:fresh-checkout .


Regards,
John

Rick McGuire wrote:
I just got back from a 2 week vacation and am trying to get caught 
back up again.  When I do a maven m:update on my working build from 
2 weeks ago, I'm getting the following message followed by a hang:


m:update:
   [exec] At revision 430039.
   [exec] Authentication realm: https://svn.codehaus.org:443 openejb 
Repo


I get similar behavior when I checkout out a fresh build and do a 
maven m:fresh-checkout.  Is this a glitch with the codehaus svn or 
should I be using something else now to access a build?


Rick

Re: Java Service Wrapper or Commons Daemon?


On 8/9/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

I've never used commons-daemon, but JSW is very cool and
works nicely.  Is there any specific features not covered by JSW
that we would need ?


No not really - I just wondered if anyone had used both and could
recommend one over the other.

James


On 8/9/06, James Strachan [EMAIL PROTECTED] wrote:

 Anyone have any experience of these 2 solutions to know which one is
 the best to use when creating a windows/unix service?

 http://wrapper.tanukisoftware.org/doc/english/introduction.html
 http://jakarta.apache.org/commons/daemon/index.html

 It'd be nice to have a service for ActiveMQ - am just not sure which
 one we should use.

 Clearly the latter is also hosted at Apache so we're more likely to be
 able to patch it if it has issues. The latter is also used by Tomcat
 so is very well used.

 Anyone used both before who could offer feedback?

 --

 James
 ---
 http://radio.weblogs.com/0112098/




--
Cheers,
Guillaume Nodet





--

James
---
http://radio.weblogs.com/0112098/

[jira] Resolved: (AMQ-872) Don't monitor activity on vm transports

2006-08-09 Thread Rob Davies (JIRA)

 [ https://issues.apache.org/activemq/browse/AMQ-872?page=all ]

Rob Davies resolved AMQ-872.


Resolution: Fixed

if TransportServer is vm - don't initialize Inactivity Monitor

 Don't monitor activity on vm transports
 ---

 Key: AMQ-872
 URL: https://issues.apache.org/activemq/browse/AMQ-872
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Reporter: Rob Davies
 Assigned To: Rob Davies
 Fix For: 4.0.3


 currently all transport servers montitor transport channels for activity - 
 closing down blocked transports. This can occassionally result in  stranged 
 side-affects for  networks - which use an inbound vm:// channel to the broker 
 in their communications

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Accessing the openejb code?


John Sisson wrote:
It appears https access for OpenEJB non-committers isn't available any 
more.  AFAIK the maven build scripts have been updated to take this 
into account, but to be able to use them you will need to do an svn 
update manually, delete the openejb directory and then try a  maven 
m:fresh-checkout .
I'm not sure I understand this.  If I try to do a svn update manually, 
it still requests authenticationand I certainly don't want to delete 
the openejb dir, because I've got working updates I need to preserve.  I 
also would have thought that checking out a fresh copy would do the 
correct thing, but that's causing me problems too.


Rick



Regards,
John

Rick McGuire wrote:
I just got back from a 2 week vacation and am trying to get caught 
back up again.  When I do a maven m:update on my working build from 
2 weeks ago, I'm getting the following message followed by a hang:


m:update:
   [exec] At revision 430039.
   [exec] Authentication realm: https://svn.codehaus.org:443 
openejb Repo


I get similar behavior when I checkout out a fresh build and do a 
maven m:fresh-checkout.  Is this a glitch with the codehaus svn or 
should I be using something else now to access a build?


Rick

[jira] Created: (GERONIMO-2304) Can't deploy on minimal assemblies produced with m2 build

2006-08-09 Thread Joe Bohn (JIRA)

Can't deploy on minimal assemblies produced with m2 build
-

 Key: GERONIMO-2304
 URL: http://issues.apache.org/jira/browse/GERONIMO-2304
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: deployment
Affects Versions: 1.2
Reporter: Joe Bohn
 Assigned To: Joe Bohn
 Fix For: 1.2


The deployer.jar isn't being included in the minimal assemblies for jetty or 
tomcat so it isn't possible to deploy from the command line.   To correct this 
we need to add the online-deployer to the pom.xml for the minimal assemblies.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (GERONIMO-2304) Can't deploy on minimal assemblies produced with m2 build

2006-08-09 Thread Joe Bohn (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2304?page=all ]

Joe Bohn resolved GERONIMO-2304.


Resolution: Fixed

committed to trunk:
Sendingm2-assemblies\geronimo-jetty-minimal\pom.xml
Sendingm2-assemblies\geronimo-tomcat-minimal\pom.xml
Transmitting file data ..
Committed revision 430054.

 Can't deploy on minimal assemblies produced with m2 build
 -

 Key: GERONIMO-2304
 URL: http://issues.apache.org/jira/browse/GERONIMO-2304
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 1.2
Reporter: Joe Bohn
 Assigned To: Joe Bohn
 Fix For: 1.2


 The deployer.jar isn't being included in the minimal assemblies for jetty or 
 tomcat so it isn't possible to deploy from the command line.   To correct 
 this we need to add the online-deployer to the pom.xml for the minimal 
 assemblies.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: jbi:embedded...


Any luck on this issue ?
Else please raise a JIRA and attach your m2 project as a test case ?

On 8/8/06, Terry Cox [EMAIL PROTECTED] wrote:


 If you put commons-pool as a dependency of your project, the
 jbi:embeddedServicemix goal will put it in the classpath.


I tried that, but it didn't make any difference. (against HEAD from
yesterday afternoon)


Terry





--
Cheers,
Guillaume Nodet

Re: Accessing the openejb code?

2006-08-09 Thread John Sisson

Sorry, wasn't completely clear.  If you didn't have changes in openejb 
to preserve then the following should work:


1. do an svn update of geronimo (not openejb) so you get the updated 
maven.xml file

2. delete the openejb folder under geronimo
3. do a maven m:fresh-checkout in the geronimo directory - this will 
then check out openejb using http instead of https.


But since you do have updates to preserve you could try using the svn 
switch command, e.g. ( I haven't tested this..)


svn switch --relocate 
https://svn.codehaus.org/openejb/branches/v2_1/openejb2 
http://svn.codehaus.org/openejb/branches/v2_1/openejb2


John


Rick McGuire wrote:

John Sisson wrote:
It appears https access for OpenEJB non-committers isn't available 
any more.  AFAIK the maven build scripts have been updated to take 
this into account, but to be able to use them you will need to do an 
svn update manually, delete the openejb directory and then try a  
maven m:fresh-checkout .
I'm not sure I understand this.  If I try to do a svn update manually, 
it still requests authenticationand I certainly don't want to 
delete the openejb dir, because I've got working updates I need to 
preserve.  I also would have thought that checking out a fresh copy 
would do the correct thing, but that's causing me problems too.


Rick



Regards,
John

Rick McGuire wrote:
I just got back from a 2 week vacation and am trying to get caught 
back up again.  When I do a maven m:update on my working build 
from 2 weeks ago, I'm getting the following message followed by a hang:


m:update:
   [exec] At revision 430039.
   [exec] Authentication realm: https://svn.codehaus.org:443 
openejb Repo


I get similar behavior when I checkout out a fresh build and do a 
maven m:fresh-checkout.  Is this a glitch with the codehaus svn or 
should I be using something else now to access a build?


Rick

Re: Maven2... we are almost there!

2006-08-09 Thread Joe Bohn

I applied a fix for https://issues.apache.org/jira/browse/GERONIMO-2304 
to correct the problem with the missing deployer.jar in the minimal 
assemblies.


Joe


Joe Bohn wrote:
Ok, once I learned to ignore the errors (and work around the windows 
pathlength issues) I was able to get a successful build.  Things went 
pretty smoothly ... nice work!!!


There seems to be a problem with the minimal assemblies.  They do not 
include the deployer.jar in the image which kinda makes it difficult to 
deploy things.   However, when I deployed my application into the 
minimal assembly using the deployer from the j2ee assembly it seemed to 
work well!


Joe

David Jencks wrote:



On Aug 8, 2006, at 8:16 AM, Joe Bohn wrote:


I'm trying to build with m2 on windows with some suspicious results.

Right now I'm getting a number of errors just trying to run bootstrap.

One of my windows machines claims that it is successful while the  
other one fails with this error:

[ERROR] BUILD ERROR
[INFO]  
-- 
--
[INFO] Destination c:\geronimo\m2-assemblies\geronimo-tomcat-j2ee 
\target\archive-tmp\repository\org\apache\geronimo\configs 
\webconsole-tomcat\1.2-SNAPSHOT\webconsole-tomcat-1.2-SNAPSHOT.car  
already exists!
[INFO]  
-- 
--

[INFO] For more information, run Maven with the -e switch
[INFO]  
-- 
--

[INFO] Total time: 5 minutes 3 seconds
[INFO] Finished at: Tue Aug 08 09:24:29 EDT 2006
[INFO] Final Memory: 55M/104M
[INFO]  
-- 
--

bootstrap: Bootstrap failed in stage assemble

I was talking with Prasad offline on this and he thinks that the  
failure is because of the windows long name issue causing the  
cleanup to fail. I'll manually clean things up and try again on  that 
machine.




However, both machines received a ton of other errors.   Are all of  
these excepted problems?  If so, then if we can't clean them up I  
think we should at least warn people to expect them.


Here are the errors that were in the logs (I can't attach the logs  
because they are too large).




I believe most or all of these were always happening, we just see  
them now  because jason figured out how to set up log4j for the tests  
properly -- previously all this was not getting recorded in any  
obvious place.


thanks
david jencks



several of these:

09:09:01,062 ERROR [GBeanInstanceState] Error while starting; GBean  
is now in the FAILED state: abstractName=test/3/3.3/bar? 
j2eeType=GBean,name=gbean3


java.lang.RuntimeException: FAILING
at  
org.apache.geronimo.kernel.config.ConfigurationManagerTest.checkFail 
(ConfigurationManagerTest.java:663)
at  
org.apache.geronimo.kernel.config.ConfigurationManagerTest.access 
$300(ConfigurationManagerTest.java:54)
at org.apache.geronimo.kernel.config.ConfigurationManagerTest 
$TestBean.init(ConfigurationManagerTest.java:809)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native  
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance 
(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance 
(DelegatingConstructorAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance 
(GBeanInstance.java:933)
at  
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( 
GBeanInstanceState.java:267)
at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start 
(GBeanInstanceState.java:102)
at  
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive 
(GBeanInstanceState.java:124)
at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive 
(GBeanInstance.java:540)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean 
(BasicKernel.java:379)
at  
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguration 
GBeans(ConfigurationUtil.java:374)
at  
org.apache.geronimo.kernel.config.KernelConfigurationManager.start 
(KernelConfigurationManager.java:187)
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager.restartCo 
nfiguration(SimpleConfigurationManager.java:628)
at  
org.apache.geronimo.kernel.config.SimpleConfigurationManager.restartCo 
nfiguration(SimpleConfigurationManager.java:588)
at  
org.apache.geronimo.kernel.config.ConfigurationManagerTest.testRestart 
Exception(ConfigurationManagerTest.java:236)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)
at

Re: Java Service Wrapper or Commons Daemon?

2006-08-09 Thread -=Kobye=-


javaservice is very good in window

 jboss and  activemq and james work well using javaservice as windows
service.

 I run jboss and activemq and james in this way.
--
I love Java!
I love Sports!
I love this Game !

QQ:33093778
MSN:[EMAIL PROTECTED]

home:http://www.jsports.org
blog:http://blog.csdn.net/jsports
  http://blog.matrix.org.cn/page/jsports
--

Re: Java Service Wrapper or Commons Daemon?

2006-08-09 Thread -=Kobye=-


more important ,it's very easy to use.
--
I love Java!
I love Sports!
I love this Game !

QQ:33093778
MSN:[EMAIL PROTECTED]

home:http://www.jsports.org
blog:http://blog.csdn.net/jsports
  http://blog.matrix.org.cn/page/jsports
--

Re: Build failure on branches 1.1.1

2006-08-09 Thread Kevan Miller


Looks like we're stuck halfway in updating for the release.
branches/1.1.1 needs to be updated to checkout openejb/branches/ 
v2_1_1/openejb2


Hogstrom, are you doing that?

--kevan

--kevan

On Aug 9, 2006, at 3:28 AM, Vamsavardhana Reddy wrote:

Build is failing since OpenEJB is looking for geronimo-xxx-1.1.2- 
SNAPHOT jars .

Re: M2 : car-maven-plugin and geronimo-plugin.xml files

2006-08-09 Thread anita kulshreshtha

inline..

--- Jason Dillon [EMAIL PROTECTED] wrote:

 On Aug 7, 2006, at 10:33 PM, anita kulshreshtha wrote:
  This code is from servlets-examples-jetty config (rev 429124):
 resources
  resource
  directory${pom.basedir}/src/conf/directory
  targetPathMETA-INF/targetPath
  includes
  includegeronimo-plugin.xml/include
  /includes
  filteringtrue/filtering
  /resource
  /resources
 
 This code has been added to many applications config. Which
 means
  that you are trying to write it yourself and have no intention of  
  using
  the patch.
 
 I was simply reusing the existing Maven2 resources plugin to handle  
 filtering of resources.


This high quality code does not do what it is supposed to do, i.e. put
geronimo-plugin.xml in the generated car.


 
 I looked over your patch and could not apply it directly due to the  
 number of other changes made to the tree since the patch was  
 originally crafted.
 
 
  Why did you ask me to make the patch?
 
 I asked you to roll new patches against m2migration and not off of  
 trunk so that I could quickly verify and apply them.


The patch on July 27th was for m2migration and it is clearly written. 



 
 
  Wow.. I don't blame you for exercising the power of a committer.
 you
  get to commit code that does nothing and reject the code that
 works!
  You have the power to shut down other peoples work.
 
 I am starting to take offense to some of these comments you are  
 making.  I'm not sure if you are trying to goat me into a conflict or
  
 if you are trying to resolve the work you have done and move forward.
 
 :-(
 
 
  Jason, I was also aware of the issues with the code and had been
  wanting to fix them and add more functionality. You are constantly
  changing the code that I wrote without any communication. You have 
 
  made
  it _impossible_ for me to work on this code. I am not saying that
 you
  are doing it intentionally.
 
 Since these commits end up with my user id attached to them, I am not
  
 willing to commit something that does not meet my standards for  
 quality.  I am not trying to invalidate your work, I am trying to get
  
 our m2 build functional and at the same time ensure a high standard  
 of quality for the code that supports it.


FYI, the code you are talking about was already committed by David
Jencks! David helped me write the plugin by expaining how the configs
work. He patiently reviewed massive patches, tested them, committed
them and made sure that the first server could be started. 


 
 
  IMO, you should have accepted the code
  because it provided the required functionality and allowed me to
 make
  improvements.
 
 The code submitted in the patches that I reviewed (and some that I  
 committed and then changed) were not using the Mojo API appropriately
  
 or effectively.  Just because a chunk of code works does not mean  
 that it should be blindly applied to the tree.


Isn't it because you added Mojo for the code that is not even being
used?


 
 I accepted the bulk of the code and cleaned it up to meet my  
 standards before I committed it.  Though some of your code I have not
  
 even begun to review since it is scattered amongst several issues and
  
 then into several patches in those issues, which makes it much harder
  
 for me to quickly verify and commit.
 
 Last time I checked the new patches are still using velocity and  
 custom file deletion bits instead of using the existing Plexus  
 support tools that handle this for you


The file deletion code is straight out of geronimo! If it is being used
in Geronimo, it is good enough for me. Why would I use Plexus?

BTW, many months ago *when you were not involved in this effort*, David
suggested that we should generate classpath dynamically. I was waiting
for the first server to start before I attempted that. That is why the
classPath was used as a massive string. It was only temporary.


 and nothing is commented. 
  
 So it is much more difficult for me to simply commit this.
 
 
  I agree with Hiram Chirino on this subject. I am quoting
  from a conversation on the list :
 

http://www.nabble.com/Re%3A--RTC--ActiveMQ-GBean-modules-p4867711.html
 
  Perhaps I should start a new thread on this thought, but I just  
  wanted
  to comment that we need to be careful about how critical and the
 level
  of perfection that we expect from the contributed patches.  I would
  say that if a patch does not regress the project and it moves it
  forward in the right direction, the patch should be accepted even
 if
  it's not perfect.
 
  It kind of reminds me of something David B told me once, if the
 code
  is perfect and stable, you won't be able to build a community
 around
  the project it since it just works.  This makes sense to me.  If
 the
  code is 80% of the way there, then you give an opportunity for
 folks
  to join

Re: Proposal to change the tooling version to be 3.0-incubating-SNAPSHOT

2006-08-09 Thread Ramon Buckland


+1 here also

Here is what I use to do it :-)
grep -lR SNAPSHOT * | egrep (xml|properties)$ | xargs -l1 -iXX perl 
-pi.sm-b4-IC-change.incubating.orig -e 
's/(3.0-incubating-SNAPSHOT|3.0-SNAPSHOT|1.0-i

ncubating-SNAPSHOT)/3.0-2006-08-02-r427980/' XX



Philip Dodds wrote:

+1 for having everthing sync up on 3.0

P

On 8/8/06, Guillaume Nodet [EMAIL PROTECTED] wrote:


I was wondering if we should change the maven plugin / archetype version
to
be in sync with the container / components.
Currently, everything as the same release cycle, so I do not really see
the
point in having a 3.0 for container and 1.0 for
tooling.  I think it may be confusing for users.

--
Cheers,
Guillaume Nodet

Re: Proposal to change the tooling version to be 3.0-incubating-SNAPSHOT


Wow, thx.
I don't understand what it does, but i will try it :)

On 8/9/06, Ramon Buckland [EMAIL PROTECTED] wrote:


+1 here also

Here is what I use to do it :-)
grep -lR SNAPSHOT * | egrep (xml|properties)$ | xargs -l1 -iXX perl
-pi.sm-b4-IC-change.incubating.orig -e
's/(3.0-incubating-SNAPSHOT|3.0-SNAPSHOT|1.0-i
ncubating-SNAPSHOT)/3.0-2006-08-02-r427980/' XX



Philip Dodds wrote:
 +1 for having everthing sync up on 3.0

 P

 On 8/8/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

 I was wondering if we should change the maven plugin / archetype
version
 to
 be in sync with the container / components.
 Currently, everything as the same release cycle, so I do not really see
 the
 point in having a 3.0 for container and 1.0 for
 tooling.  I think it may be confusing for users.

 --
 Cheers,
 Guillaume Nodet








--
Cheers,
Guillaume Nodet

Re: SM-512 and SM-521


Agreed, but maybe the servicemix-bpe component could be enhanced.
If i recall, the main problem is that bpe does not have a way to provide
an asynchronous response when a request/response pattern is used
(need to check once again, though).  However, for InOnly MEPs, we
could easily use an asynchonous send.  ... and you could use
bpel correlations to use InOnly meps for request and response instead
of an InOut mep.
Would you please raise a JIRA ? imho, this problem is specific
to servicemix-bpe and could be fixed asap.

On 8/9/06, Ramon Buckland [EMAIL PROTECTED] wrote:


It would defintiely be something that can cause problems.
We are currently trying to resolve this. It seems to rear
it's head (SM-512) on Windows, more than Linux, this has
me baffled

servicemix-bpe ... JbiInvokeAction only ever sends out a sendSync()
when invoking a partner (JBI Component).

The BPEL spec discussed correlation-sets as method of performing async
calls.
We can see that flows and sequences control the threading of
servicemix-bpe
but because there is a sendSync for every message going out, it means
the threadpool
can get eaten up pretty quickly.

my 2 cents.


Guillaume Nodet wrote:
 SM-512 is a pretty big issue, but it does not have by itself any
solution
 (see my comment in JIRA).
 However, SM-521 could be implemented to be able to easily tune thread
 pools
 and queue sizes to
 avoid deadlocks.  Though it may require quite an amount of
 refactoring, i'm
 wondering if we should
 implement it for 3.0 ?






--
Cheers,
Guillaume Nodet

Re: Start JavaMail by default in 1.1.1?

Starting it is fine but it does require some customization as Aaron pointed out.  Will the start be 
graceful enough that users will know that they need to customize it?  Perhaps a WARNING message 
issues at startup if it hasn't been configured would be nice.


Rick McGuire wrote:

Aaron Mulder wrote:

I don't see a great reason that we're not starting the JavaMail module
by default.  Granted, the user may need to change the SMTP server, but
it's going to be easier if they don't need to enable the module too
(e.g. the console usually doesn't see disabled GBeans, and the
load=false is easy enough to miss in config.xml).
I think this is probably a good idea.  Most of the problems I've seen 
with users attempting to use javamail have been caused by the fact the 
javamail module has not been started.  This usually manifests as a 
provider resolution failure because the transport jars are not showing 
up in the classpath.  Because the spec jars ARE there by default, this 
error doesn't show up until it is used.





What do you think?

Thanks,
Aaron

Re: Build failure on branches 1.1.1


done

Kevan Miller wrote:

Looks like we're stuck halfway in updating for the release.
branches/1.1.1 needs to be updated to checkout 
openejb/branches/v2_1_1/openejb2


Hogstrom, are you doing that?

--kevan

--kevan

On Aug 9, 2006, at 3:28 AM, Vamsavardhana Reddy wrote:

Build is failing since OpenEJB is looking for 
geronimo-xxx-1.1.2-SNAPHOT jars .

[jira] Assigned: (GERONIMODEVTOOLS-52) Move away from generic server framework

 [ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-52?page=all ]

Sachin Patel reassigned GERONIMODEVTOOLS-52:


Assignee: Sachin Patel

 Move away from generic server framework
 ---

 Key: GERONIMODEVTOOLS-52
 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-52
 Project: Geronimo-Devtools
  Issue Type: New Feature
  Components: eclipse-plugin
Reporter: Sachin Patel
 Assigned To: Sachin Patel
 Fix For: 1.x


 As more geronimo specific features are needed, using the generic server 
 framework in wtp is no longer suitable and the current server adapter is 
 quickly outgrowing its need for it.  The server support needs to be 
 re-written to provide a complete custom implementation for geronimo server 
 support in WTP.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: M2 : car-maven-plugin and geronimo-plugin.xml files

I get the sense that both of you are a bit frustrated.  The transition to the new RTC development 
model has been challenging for all.  The PMC has not kept up with the number of reviews and that has 
allowed the codebase to drift while patches then get stale.


Recently we've made several steps forward to improve the process.  Several new PMC members have been 
added in the last few weeks that are active committers to the project so the ability to provide 
timely feedback has been improved.  Along with some better mechanisms to track what needs to be 
reviewed so we can quickly address them.  (I think we got the pluggable JAAC completed last night).


All this to say it has made us stumble a bit in the process, we're not perfect yet, but we're making 
some important headway.


Everyone who has worked on the Maven 2 conversion needs to get some kudos as it is slightly larger 
than a bread box :) and given the somewhat binary nature of the change does not lend itself well to 
using patches as the vehicle to get the job done.


All that said, Jason, as your going through the patches and making changes what is the primary way 
to get feedback to the person who contributed the patch?  It sounds like you have some good feedback 
that would help Anita produce patches that you are both in more agreement on.  Also, it sounds like 
some of the changes are preferences based on style.  It would be a fair debate as to one should use 
Plexus or Geronimo infrastructure for the file delete activity.


All this said, you guys are to be commended for the progress you've made.  For the time being the 
review and collaboration feels like we've gone from a sprint to a jog but as we hit our stride I 
hope the pace will pick up as well.


anita kulshreshtha wrote:

inline..

--- Jason Dillon [EMAIL PROTECTED] wrote:


On Aug 7, 2006, at 10:33 PM, anita kulshreshtha wrote:

This code is from servlets-examples-jetty config (rev 429124):
   resources
resource
directory${pom.basedir}/src/conf/directory
targetPathMETA-INF/targetPath
includes
includegeronimo-plugin.xml/include
/includes
filteringtrue/filtering
/resource
/resources

   This code has been added to many applications config. Which

means
that you are trying to write it yourself and have no intention of  
using

the patch.
I was simply reusing the existing Maven2 resources plugin to handle  
filtering of resources.



This high quality code does not do what it is supposed to do, i.e. put
geronimo-plugin.xml in the generated car.


I looked over your patch and could not apply it directly due to the  
number of other changes made to the tree since the patch was  
originally crafted.




Why did you ask me to make the patch?
I asked you to roll new patches against m2migration and not off of  
trunk so that I could quickly verify and apply them.



The patch on July 27th was for m2migration and it is clearly written. 







Wow.. I don't blame you for exercising the power of a committer.

you

get to commit code that does nothing and reject the code that

works!

You have the power to shut down other peoples work.
I am starting to take offense to some of these comments you are  
making.  I'm not sure if you are trying to goat me into a conflict or
 
if you are trying to resolve the work you have done and move forward.


:-(



Jason, I was also aware of the issues with the code and had been
wanting to fix them and add more functionality. You are constantly
changing the code that I wrote without any communication. You have 
made

it _impossible_ for me to work on this code. I am not saying that

you

are doing it intentionally.

Since these commits end up with my user id attached to them, I am not
 
willing to commit something that does not meet my standards for  
quality.  I am not trying to invalidate your work, I am trying to get
 
our m2 build functional and at the same time ensure a high standard  
of quality for the code that supports it.



FYI, the code you are talking about was already committed by David
Jencks! David helped me write the plugin by expaining how the configs
work. He patiently reviewed massive patches, tested them, committed
them and made sure that the first server could be started. 






IMO, you should have accepted the code
because it provided the required functionality and allowed me to

make

improvements.
The code submitted in the patches that I reviewed (and some that I  
committed and then changed) were not using the Mojo API appropriately
 
or effectively.  Just because a chunk of code works does not mean  
that it should be blindly applied to the tree.



Isn't it because you added Mojo for the code that is not even being
used?


I accepted the bulk of the code and cleaned it up to meet my  
standards before I committed it.  Though some of your code I have not
 
even begun to review since it is scattered

Re: Proposal to change the tooling version to be 3.0-incubating-SNAPSHOT

2006-08-09 Thread Ramon Buckland


Instead of hand carving the version changes through the files.

It could be more  elegantly written as

find . -type f -name '*.xml' -or -name '*.properties' | xargs -l1 grep 
-l SNAPSHOT | xargs -l1 perl -pi.backup -s 
's/(3.0-incubating-SNAPSHOT|3.0-SNAPSHOT|1.0-i

ncubating-SNAPSHOT)/3.0-2006-08-02-r427980/'

Which can be translated as
#
# Find all the files that end in XML or properties
#
find . -type f -name '*.xml' -or -name '*.properties' \

#
# filter so we ONLY get the ones that contain the word SNAPSHOT
# but just list the file .. (don't grep it's contents)
# xargs is a magic little streamliner that takes a list and
# feeds them into the command that follows, it has a magic option of
# -l1, meaning .. 1 at a time ..
#
xargs -l1 grep -l SNAPSHOT \

#
# now do the textual replacement in that file that we have found.
#  use perl, which we also backup the file before it makes the change
#  -pi.backup (eg: pom.xml.backup)
#
# The regexp says, change any occurence of 3.0-incubating-SNAPSHOT, or or
# to the version string 3.0-2006-08-02-r427980
#
xargs -l1 perl -pi.backup -s 's/(3.0-incubating-SNAPSHOT|3.0-SNAPSHOT|1.0-i
ncubating-SNAPSHOT)/3.0-2006-08-02-r427980/'


hope that is a little clearer :-)

cheers
ramon

Guillaume Nodet wrote:

Wow, thx.
I don't understand what it does, but i will try it :)

On 8/9/06, Ramon Buckland [EMAIL PROTECTED] wrote:


+1 here also

Here is what I use to do it :-)
grep -lR SNAPSHOT * | egrep (xml|properties)$ | xargs -l1 -iXX perl
-pi.sm-b4-IC-change.incubating.orig -e
's/(3.0-incubating-SNAPSHOT|3.0-SNAPSHOT|1.0-i
ncubating-SNAPSHOT)/3.0-2006-08-02-r427980/' XX



Philip Dodds wrote:
 +1 for having everthing sync up on 3.0

 P

 On 8/8/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

 I was wondering if we should change the maven plugin / archetype
version
 to
 be in sync with the container / components.
 Currently, everything as the same release cycle, so I do not 
really see

 the
 point in having a 3.0 for container and 1.0 for
 tooling.  I think it may be confusing for users.

 --
 Cheers,
 Guillaume Nodet

soap-binding sample error

2006-08-09 Thread ajayk_goel


Sorry if it is duplicate post, I did try searching for this error though...

I am new to servicemix and am trying to run the soap-binding sample provided
by 3.0 M2.

When I try to run the xml file by saying (servicemix is in my path)

ant setup servicemix servicemix.xml

I get an error
Target `servicemix' does not exist in this project.

What am I missing?
-- 
View this message in context: 
http://www.nabble.com/soap-binding-sample-error-tf2079610.html#a5728499
Sent from the ServiceMix - Dev forum at Nabble.com.

[Committing] GERONIMO-2277 Remove TransactionContextManager

2006-08-09 Thread Dain Sundstrom

With votes from Jeff, Jencks and Matt, I am going to committ this  
patch today, so please let me know if you're going to commit  
something significant so I can avoid conflicts :)


-dain

On Aug 7, 2006, at 4:07 PM, Dain Sundstrom wrote:

Ok all fixed.  Jason fixed the logging issue, and the other problem  
was that backport-concurrent-util was not in the manifest classpath  
of the server jar.


-dain

On Aug 7, 2006, at 10:05 AM, Dain Sundstrom wrote:


On Aug 7, 2006, at 12:09 AM, David Jencks wrote:

The notcm branch builds fine for me under m2 but the j2ee-jetty  
server does not start for me at the moment.  Apparently the  
TransactionManager doesn't start.  As noted in another post I  
don't get any log files which has so far inhibited me from  
investigating further.  Is this just my setup?


Don't know.  I'll take a look

-dain

[jira] Created: (SM-528) using the new ClientFactory for the JSR181 proxy inside jsr181 service unit

2006-08-09 Thread James Bradt (JIRA)

using the new ClientFactory for the JSR181 proxy inside jsr181 service unit
---

 Key: SM-528
 URL: https://issues.apache.org/activemq/browse/SM-528
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-jsr181
Affects Versions: 3.0-M2
Reporter: James Bradt
Priority: Minor


Unfortunately, you currently need a reference to the JBI container (or a
ComponentContext).
But neither the JBIContainer nor the ComponentContext are available at the
time the
xbean file is loaded.
This could now be solved by using the new ClientFactory which is available
in JNDI, but has
been coded yet.  Could you please raise a JIRA for that ?

For now, you need to create the JbiProxy programmaticaly from your POJO.

On 8/8/06, James Bradt [EMAIL PROTECTED] wrote:

 I've taken a look at the unit test for jsr181 proxy (and the small amount
 of
 info in the wiki area), but I can't seem to answer this question.

 Can a jsr181:proxy tag be defined within the xbean.xml for a jsr181
 service
 unit, or can it only be used within a lwcontainer service unit?

 If I can use it within a jsr181 service unit, what is the container name
 that I should I reference within the jsr181:proxy element?

 Thanks,
 James






-- 
Cheers,
Guillaume Nodet


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Start JavaMail by default in 1.1.1?


Matt Hogstrom wrote:
Starting it is fine but it does require some customization as Aaron 
pointed out.  Will the start be graceful enough that users will know 
that they need to customize it?  Perhaps a WARNING message issues at 
startup if it hasn't been configured would be nice.


Rick McGuire wrote:

Aaron Mulder wrote:

I don't see a great reason that we're not starting the JavaMail module
by default.  Granted, the user may need to change the SMTP server, but
it's going to be easier if they don't need to enable the module too
(e.g. the console usually doesn't see disabled GBeans, and the
load=false is easy enough to miss in config.xml).
I think this is probably a good idea.  Most of the problems I've seen 
with users attempting to use javamail have been caused by the fact 
the javamail module has not been started.  This usually manifests as 
a provider resolution failure because the transport jars are not 
showing up in the classpath.  Because the spec jars ARE there by 
default, this error doesn't show up until it is used.
Well, it sort of requires customization.  One way to use it is to 
request the javamail resource, then request a transport object from the 
resource.  In that mode, yes, customization is required.  However, most 
of the questions I've been seeing from the user list involved people who 
just wish to use the javamail APIs directly.  They don't require the 
configured javamail resource, just a full set of javamail jars.  Since 
the provider jars don't get pulled in unless the javamail config is 
loaded, the smtp provider can't be located.  These users are required to 
make a config change just to get the jar files loaded.  We could satisfy 
the needs of these users by redoing the dependencies a bit and 
decoupling the providers from the mail config.








What do you think?

Thanks,
Aaron

Re: Start JavaMail by default in 1.1.1?

2006-08-09 Thread Aaron Mulder


On 8/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote:

Starting it is fine but it does require some customization as Aaron pointed 
out.  Will the start be
graceful enough that users will know that they need to customize it?  Perhaps a 
WARNING message
issues at startup if it hasn't been configured would be nice.


It doesn't always need to be configured even if you're using it as a
J2EE resource -- many Linux boxes come with an MTA already running, so
the default mail server of localhost may be perfectly reasonable.

Thanks,
Aaron


Rick McGuire wrote:
 Aaron Mulder wrote:
 I don't see a great reason that we're not starting the JavaMail module
 by default.  Granted, the user may need to change the SMTP server, but
 it's going to be easier if they don't need to enable the module too
 (e.g. the console usually doesn't see disabled GBeans, and the
 load=false is easy enough to miss in config.xml).
 I think this is probably a good idea.  Most of the problems I've seen
 with users attempting to use javamail have been caused by the fact the
 javamail module has not been started.  This usually manifests as a
 provider resolution failure because the transport jars are not showing
 up in the classpath.  Because the spec jars ARE there by default, this
 error doesn't show up until it is used.



 What do you think?

 Thanks,
 Aaron

Re: soap-binding sample error


These are several commands.
Try
  ant setup
then
  servicemix servicemix.xml

On 8/9/06, ajayk_goel [EMAIL PROTECTED] wrote:



Sorry if it is duplicate post, I did try searching for this error
though...

I am new to servicemix and am trying to run the soap-binding sample
provided
by 3.0 M2.

When I try to run the xml file by saying (servicemix is in my path)

ant setup servicemix servicemix.xml

I get an error
Target `servicemix' does not exist in this project.

What am I missing?
--
View this message in context:
http://www.nabble.com/soap-binding-sample-error-tf2079610.html#a5728499
Sent from the ServiceMix - Dev forum at Nabble.com.





--
Cheers,
Guillaume Nodet

Re: Start JavaMail by default in 1.1.1?


sounds good to me

Aaron Mulder wrote:

On 8/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Starting it is fine but it does require some customization as Aaron 
pointed out.  Will the start be
graceful enough that users will know that they need to customize it?  
Perhaps a WARNING message

issues at startup if it hasn't been configured would be nice.


It doesn't always need to be configured even if you're using it as a
J2EE resource -- many Linux boxes come with an MTA already running, so
the default mail server of localhost may be perfectly reasonable.

Thanks,
Aaron


Rick McGuire wrote:
 Aaron Mulder wrote:
 I don't see a great reason that we're not starting the JavaMail module
 by default.  Granted, the user may need to change the SMTP server, but
 it's going to be easier if they don't need to enable the module too
 (e.g. the console usually doesn't see disabled GBeans, and the
 load=false is easy enough to miss in config.xml).
 I think this is probably a good idea.  Most of the problems I've seen
 with users attempting to use javamail have been caused by the fact the
 javamail module has not been started.  This usually manifests as a
 provider resolution failure because the transport jars are not showing
 up in the classpath.  Because the spec jars ARE there by default, this
 error doesn't show up until it is used.



 What do you think?

 Thanks,
 Aaron

[jira] Commented: (AMQ-855) Add support for prefetchSize = 0

2006-08-09 Thread Vadim Pesochinskiy (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36730 ] 

Vadim Pesochinskiy commented on AMQ-855:


James  Hiram,

I understand that you are trying to keep the scope of AMQ in check and I 
appreciate this as I believe we will benefit in quality. However, I just do not 
think I can proceed with using this product, because it does not satisfy my 
project's requirements. The requirements are not artificial and I am sure they 
cannot be resolved with either of the solutions that you proposed. I do not 
want to abuse your CPU with long explanation of why it is so.

Due to whatever reasons I have multiple synchronous consumers (no listener, 
receive*(*) methods) and some of them are not used for extended periods of 
time. This results in the message broker not dispatching messages. Is this not 
a bug?!!!

I do not know if setting prefetchSize=0 is the solution, but somehow AMQ needs 
to support the case when consumers are not getting any messages until they 
request them.

- Vadim.


 Add support for prefetchSize = 0
 

 Key: AMQ-855
 URL: https://issues.apache.org/activemq/browse/AMQ-855
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 4.0, 4.0.1, 4.0.2
 Environment: any
Reporter: Vadim Pesochinskiy
Priority: Critical
 Fix For: 4.2


 This feature would enable to support following test case:
 2 servers are processing 3 submitted jobs with following processing times 10 
 min, 1 min, 1 min. This sequence should finish in 10 minutes as one service 
 will pick up the 10 minutes job, meanwhile the other one should manage the 
 two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute 
 jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes 
 instead of 10.
 This is simplification of the real scenario where I have about 30 consumers 
 submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems:
  Messages are sitting in prefetch buffer are not available to processors, 
 which results in a lot of idle time.
  Order of processing is random. For some reason Job # 20 is processed after 
 Job # 1500. Since senders are synchronously blocked this can result in 
 time-outs.
  Some requests are real-time, i.e. there is a user waiting, so the system 
 cannot wait, so AMQ-850 does not fix this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [Committing] GERONIMO-2277 Remove TransactionContextManager

2006-08-09 Thread David Blevins


Yay!

On Aug 9, 2006, at 9:28 AM, Dain Sundstrom wrote:

With votes from Jeff, Jencks and Matt, I am going to committ this  
patch today, so please let me know if you're going to commit  
something significant so I can avoid conflicts :)


-dain

On Aug 7, 2006, at 4:07 PM, Dain Sundstrom wrote:

Ok all fixed.  Jason fixed the logging issue, and the other  
problem was that backport-concurrent-util was not in the manifest  
classpath of the server jar.


-dain

On Aug 7, 2006, at 10:05 AM, Dain Sundstrom wrote:


On Aug 7, 2006, at 12:09 AM, David Jencks wrote:

The notcm branch builds fine for me under m2 but the j2ee-jetty  
server does not start for me at the moment.  Apparently the  
TransactionManager doesn't start.  As noted in another post I  
don't get any log files which has so far inhibited me from  
investigating further.  Is this just my setup?


Don't know.  I'll take a look

-dain

[jira] Commented: (SM-521) Tuning parameters configuration

2006-08-09 Thread Ramon Buckland (JIRA)

[ 
https://issues.apache.org/activemq/browse/SM-521?page=comments#action_36731 ] 

Ramon Buckland commented on SM-521:
---

for Component throttling, this is handling the ConfigMBeanImpl.
Every component registered with the JBIContainer will get their own Bean.

What would be nice is to have 

sm:component throttlingTimeout=500 throttlingInterval=5
   
/sm:component

How would this config translate to an XBean ? is there a magical way 
using the xbean config to also set these values ?

I am thinking that these two properties should sit on the BaseComponent class 
and on init after it is registered itself, it gets a hold of it's own MBean and 
sets the relevant values. 

Issue is, a fair few components don't extend BaseComponent but rather implement 
directly the jbi interface component.



 Tuning parameters configuration
 ---

 Key: SM-521
 URL: https://issues.apache.org/activemq/browse/SM-521
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-core
Reporter: Guillaume Nodet
 Fix For: 3.0-M3


 We need to provide a way to configure tuning parameters for servicemix:
   * thread pools (core + flows + seda queues + components )
   * queues (delivery channels + seda queues)
   * component throttling
 This may need a way to configure dummy activationSpecs (with no components, 
 only the component name)
 so that we can configure these parameters when using JBI std installation

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (XBEAN-31) [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build

[ 
http://issues.apache.org/jira/browse/XBEAN-31?page=comments#action_12426977 ] 

Matt Hogstrom commented on XBEAN-31:


Guillaume, I tried the patch and it didn't work.  Since it was fairly small I 
went ahead and manually applied the changes.  And I think this will work.

The patch is applied from geronimo/xbean/trunk via patch -p0  
XBEAN-31.matt.diff

I also corrected a typo in one of the System.outs for AsArtifactId.

Since this is your patch, I'll reset the vote and give this my +1

Cheers.

 [RTC] it would be great if the m2 plugin would automatically add the XSD and 
 .xsd.html files as artifacts into the build
 

 Key: XBEAN-31
 URL: http://issues.apache.org/jira/browse/XBEAN-31
 Project: XBean
  Issue Type: Wish
  Components: maven-plugin
Reporter: james strachan
 Assigned To: Guillaume Nodet
 Fix For: 2.6

 Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff


 So that the XSD and HTML reference would be automatically deployed into the 
 m2 repository. 
 See the attach-artifact for how to do it manually in each POM. But given how 
 many projects are using the m2 plugin it would simplify our lives if the m2 
 plugin did this for us
 http://mojo.codehaus.org/build-helper-maven-plugin/howto.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (XBEAN-31) [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build

 [ http://issues.apache.org/jira/browse/XBEAN-31?page=all ]

Matt Hogstrom updated XBEAN-31:
---

Attachment: XBEAN-31.matt.diff

 [RTC] it would be great if the m2 plugin would automatically add the XSD and 
 .xsd.html files as artifacts into the build
 

 Key: XBEAN-31
 URL: http://issues.apache.org/jira/browse/XBEAN-31
 Project: XBean
  Issue Type: Wish
  Components: maven-plugin
Reporter: james strachan
 Assigned To: Guillaume Nodet
 Fix For: 2.6

 Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff


 So that the XSD and HTML reference would be automatically deployed into the 
 m2 repository. 
 See the attach-artifact for how to do it manually in each POM. But given how 
 many projects are using the m2 plugin it would simplify our lives if the m2 
 plugin did this for us
 http://mojo.codehaus.org/build-helper-maven-plugin/howto.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (XBEAN-31) [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build

 [ http://issues.apache.org/jira/browse/XBEAN-31?page=all ]

Matt Hogstrom reopened XBEAN-31:


 
Resetting vote.

 [RTC] it would be great if the m2 plugin would automatically add the XSD and 
 .xsd.html files as artifacts into the build
 

 Key: XBEAN-31
 URL: http://issues.apache.org/jira/browse/XBEAN-31
 Project: XBean
  Issue Type: Wish
  Components: maven-plugin
Reporter: james strachan
 Assigned To: Guillaume Nodet
 Fix For: 2.6

 Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff


 So that the XSD and HTML reference would be automatically deployed into the 
 m2 repository. 
 See the attach-artifact for how to do it manually in each POM. But given how 
 many projects are using the m2 plugin it would simplify our lives if the m2 
 plugin did this for us
 http://mojo.codehaus.org/build-helper-maven-plugin/howto.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (XBEAN-19) [RTC] Enable inverse classloading with the classpath element

[ 
http://issues.apache.org/jira/browse/XBEAN-19?page=comments#action_12426983 ] 

Matt Hogstrom commented on XBEAN-19:


+1...applied and tested.  Need one more vote.

 [RTC] Enable inverse classloading with the classpath element
 

 Key: XBEAN-19
 URL: http://issues.apache.org/jira/browse/XBEAN-19
 Project: XBean
  Issue Type: New Feature
  Components: server
Affects Versions: 2.4
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.6

 Attachments: XBEAN-19.patch


 We could do something like
classpath delegation=child | parent
 the default being parent

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-2248) Applications portlets: List Parent and Child components against each component

[ 
http://issues.apache.org/jira/browse/GERONIMO-2248?page=comments#action_12426984
 ] 

Matt Hogstrom commented on GERONIMO-2248:
-

I think this is fine for inclusion in 1.1.2.  Although it is an improvement 
it improves server usability.

My +1 for 1.1.2

Vamsi, can you rework the patch to spit out a stack trace when the Should Not 
Occur issue arises :)

 Applications portlets: List Parent and Child components against each component
 --

 Key: GERONIMO-2248
 URL: http://issues.apache.org/jira/browse/GERONIMO-2248
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 1.2, 1.1, 1.1.1
Reporter: Vamsavardhana Reddy
 Fix For: 1.2

 Attachments: GERONIMO-2248.patch


 Applications portlets currently provide component status and links to 
 start/stop/restart/uninstall.  They do not provide a listing of parent 
 components and child components.
 If child components are listed, a user will immediatley know what all 
 configurations will be stopped if a particular component is stopped.
 How is it useful?
 I have stopped  geronimo/system-database/1.1.1-SNAPSHOT/car to test 
 something.  Only after an error HTTP 404 was displayed next,  I realized that 
 the admin console had a dependency on 
 geronimo/system-database/1.1.1-SNAPSHOT/car.  Had there been a Child 
 Components listing next to geronimo/system-database/1.1.1-SNAPSHOT/car, it 
 would have avoided the surprise.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1716) Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console

 [ http://issues.apache.org/jira/browse/GERONIMO-1716?page=all ]

Matt Hogstrom updated GERONIMO-1716:


Fix Version/s: 1.1.2
   1.2
   (was: 1.1.1)

 Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
 

 Key: GERONIMO-1716
 URL: http://issues.apache.org/jira/browse/GERONIMO-1716
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 1.0, 1.1, 1.2
 Environment: Any
Reporter: Donald Woods
 Assigned To: Donald Woods
Priority: Minor
 Fix For: 1.1.2, 1.2

 Attachments: Geronimo-1716.patch


 Enhancement to the default PropertiesFileLoginModule and Console to encrypt 
 user passwords in users.properties.
 To do this, PropertiesFileLoginModule and Console will be updated to use the 
 SimpleEncryption utility class, just like the deployer, to read/write 
 passwords that have the {Simple} key in front of encrypted passwords.
 The loadProperties() method in PropertiesFileLoginModule will also be updated 
 to rewrite the users.properties file if it detects unencrypted passwords, 
 which will allow users to manually edit the file to update a password and 
 then have it automatically encrypted when the next login event occurs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1917) repository doesn't deal well with case insensitive file systems

 [ http://issues.apache.org/jira/browse/GERONIMO-1917?page=all ]

Matt Hogstrom updated GERONIMO-1917:


Fix Version/s: 1.1.2
   1.2
   (was: 1.1.1)
Affects Version/s: 1.1.1
   1.1.2
   1.1.x

Moving to 1.1.2 for rework and inclusion.

 repository doesn't deal well with case insensitive file systems
 ---

 Key: GERONIMO-1917
 URL: http://issues.apache.org/jira/browse/GERONIMO-1917
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: kernel
Affects Versions: 1.1, 1.1.1, 1.1.x, 1.1.2
Reporter: David Jencks
 Fix For: 1.1.2, 1.2


 If you've installed a configuration A/B/1/car and then look for a/b/1/car, 
 the repository will claim it's there on a case insensitive file system, but 
 then further logic in the config store/ manager blows up because those are 
 different artifacts.  Solution appears to be to check when locating an 
 artifact that the case from the file system matches the case you are asking 
 for.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Start JavaMail by default in 1.1.1?

2006-08-09 Thread Dain Sundstrom


+1

-dain

On Aug 9, 2006, at 10:04 AM, Matt Hogstrom wrote:


sounds good to me

Aaron Mulder wrote:

On 8/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Starting it is fine but it does require some customization as  
Aaron pointed out.  Will the start be
graceful enough that users will know that they need to customize  
it?  Perhaps a WARNING message

issues at startup if it hasn't been configured would be nice.

It doesn't always need to be configured even if you're using it as a
J2EE resource -- many Linux boxes come with an MTA already  
running, so

the default mail server of localhost may be perfectly reasonable.
Thanks,
Aaron

Rick McGuire wrote:
 Aaron Mulder wrote:
 I don't see a great reason that we're not starting the  
JavaMail module
 by default.  Granted, the user may need to change the SMTP  
server, but
 it's going to be easier if they don't need to enable the  
module too

 (e.g. the console usually doesn't see disabled GBeans, and the
 load=false is easy enough to miss in config.xml).
 I think this is probably a good idea.  Most of the problems  
I've seen
 with users attempting to use javamail have been caused by the  
fact the

 javamail module has not been started.  This usually manifests as a
 provider resolution failure because the transport jars are not  
showing
 up in the classpath.  Because the spec jars ARE there by  
default, this

 error doesn't show up until it is used.



 What do you think?

 Thanks,
 Aaron

[jira] Commented: (AMQ-850) add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages

2006-08-09 Thread Sridhar Komandur (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-850?page=comments#action_36732 ] 

Sridhar Komandur commented on AMQ-850:
--

James/Hiram,

Here is another proposal for fixing this issue.

At a high level, we need break the coupling between the messages allocated to a 
consumer and the actual act of scheduling a message, using  a  central pool 
(from which all the consumers get their messages).

I propose that the prefetch buffer just keep track of  token count, which 
indicates the messages that are available to be sent to a consumer. In effect, 
this is used to do flow control to the consumer. We can extend this to 
additional policies like high priority message tokens etc.

When a message is actually scheduled to the consumer (whatever be the policy 
used for this), an actual message is obtained from the central pool and 
dispatched to the consumer. After this, the token count is decremented.

This proposal, as a side affect, helps in minimizing reordering of messages 
unnecessarily to the consumer system (comprising of a large number of consumer 
entities).

Thanks 
Regards
- Sridhar Komandur

 add the ability to timeout a consumer to prevent a bad, hung or unused 
 consumer consumer from grabbing messages
 ---

 Key: AMQ-850
 URL: https://issues.apache.org/activemq/browse/AMQ-850
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Reporter: james strachan
 Fix For: 4.2


 If a MessageConsumer is created but not used, it still tends to get its 
 prefetch-buffer worth of messages. If it does not process them within a 
 specific time the consumer should either be closed, or the messages unacked 
 and flushed from the buffer so that the consumer does not hog the messages.
 Similarly if a consumer gets a message but then locks up without processing 
 the message we should lazily kill the consumer releasing and redelivering all 
 its messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] Commented: (AMQ-850) add the ability to timeout a consumer to

2006-08-09 Thread Komandur



Continuing my previous posting ...

Also, note that message related accounting can happen in the central pool;
for example, any dispatched messages are marked appropriately in the message
meta-data  (which consumer it was dispatched, timestamp etc). The dispatched
messages can go to the back of the pool or moved to another Ack pool
(potentially sorted by consumer specific expiry time), which can be visited
periodically(and lazily) for further cleanup/processing.

Thanks
Regards
- Sridhar Komandur
-- 
View this message in context: 
http://www.nabble.com/-jira--Created%3A-%28AMQ-850%29-add-the-ability-to-timeout-a-prefetch-buffer-to-prevent-a-single-consumer-grabbing-messages-tf2014900.html#a5731150
Sent from the ActiveMQ - Dev forum at Nabble.com.

[jira] Commented: (AMQ-850) add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages

[ 
https://issues.apache.org/activemq/browse/AMQ-850?page=comments#action_36733 ] 

james strachan commented on AMQ-850:


Vadim: agreed in the case where the consumer just never processes any messages 
and the receive() method is never called. A consumer would basically be 
terminated until a call to receive*() which would re-awaken it again. 

Though the consumer may be in the middle of processing a message but is just 
taking too long due to some hang/lock (either after calling receive() and not 
calling commit() / acknowledge() - or be inside a MessageListener method call - 
and may need to actually be closed preventing any future messages being 
dispatched.

 add the ability to timeout a consumer to prevent a bad, hung or unused 
 consumer consumer from grabbing messages
 ---

 Key: AMQ-850
 URL: https://issues.apache.org/activemq/browse/AMQ-850
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Reporter: james strachan
 Fix For: 4.2


 If a MessageConsumer is created but not used, it still tends to get its 
 prefetch-buffer worth of messages. If it does not process them within a 
 specific time the consumer should either be closed, or the messages unacked 
 and flushed from the buffer so that the consumer does not hog the messages.
 Similarly if a consumer gets a message but then locks up without processing 
 the message we should lazily kill the consumer releasing and redelivering all 
 its messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (AMQ-850) add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages

[ 
https://issues.apache.org/activemq/browse/AMQ-850?page=comments#action_36734 ] 

james strachan commented on AMQ-850:


Sridhar: I don't quite follow your suggestion. We kinda do what you suggest - 
the broker maintains a record of how many messages have been dispatched to 
which consumer together with maintaining a list of the messages which are 
targetted for different consumers (i.e. which messages could be sent to a 
consumer). The act of dispatching a message to a given consumer is the same 
thing as adding it to its prefetch buffer.

Note that the main use of the prefetch buffer is to actually physically send 
the messages to the consumer as fast as possible - up to the prefetch count - 
so that they are immediately available on the client side.

http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html

 add the ability to timeout a consumer to prevent a bad, hung or unused 
 consumer consumer from grabbing messages
 ---

 Key: AMQ-850
 URL: https://issues.apache.org/activemq/browse/AMQ-850
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Reporter: james strachan
 Fix For: 4.2


 If a MessageConsumer is created but not used, it still tends to get its 
 prefetch-buffer worth of messages. If it does not process them within a 
 specific time the consumer should either be closed, or the messages unacked 
 and flushed from the buffer so that the consumer does not hog the messages.
 Similarly if a consumer gets a message but then locks up without processing 
 the message we should lazily kill the consumer releasing and redelivering all 
 its messages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

RTC voting and in particular pluggable jacc issue

2006-08-09 Thread David Jencks

AFAICT it's not possible to find out from jira when votes on issues  
were done, nor do they get comments.  Therefore I think we need to  
ask PMC members voting on RTC issues to both vote and include a  
comment explicitly indicating that they are voting +1 as an official  
RTC vote.


In particular GERONIMO-1563 pluggable jacc has 3 pmc votes but only 2  
comments from pmc members specifically indicating a +1 RTC vote.  I  
have no way to determine if Jeff's vote was before or after he  
rejoined the PMC.  Jeff, could you clarify?


thanks
david jencks

Re: DayTrader with an AJAX based Web interface

2006-08-09 Thread Christopher Blythe

All,Here's a first pass at a new Web 2.0, AJAX-based, Web
interface for DayTrader! Take a look at and let me know what you think:
http://porky.hogstrom.org:8080/dojo_trader/daytrader.htmlFYI - I highly suggest using Firefox or Mozzilla to view this. Also, thanks to Matt Hogstrom for his assistance.This is merely a first pass that provides all of the operational features of DayTrader classic, but also leverages the various _javascript_ libraries (widget, io, storage, etc.) within the Dojo toolkit to provide a better user experience. Eventually, I would like for this to serve as an addition to DayTrader
2.0 and would like feedback and other contributions on how we can evolve DayTrader to look less like a traditional browser-based, click-and-wait type application and more like a stand-alone app. I am by no means a _javascript_ or CSS expert, so any help, recommendations, etc. would be gratefully appreciated...
Thanks...ChrisOn 3/16/06, Aaron Mulder [EMAIL PROTECTED] wrote:
That definitely sounds like an attractive thing to benchmark to me!As with the persistence options, etc. I think it would be best to be
able to run it both ways and see what you get with a traditional webinterface and compare that to an AJAX-ified interface.Thanks,AaronOn 3/16/06, J. Stan Cox
[EMAIL PROTECTED] wrote: Geronimos, I've worked on the Trade benchmark in the past that has been donated to Geronimo and is now known as DayTrader. I think it will grow and
flourish in the open source environment and become a nice showcase for Geronimo's performance and capabilities. I'minterested in adding a rich, AJAX based Web interface to DayTrader for performance research.DayTrader is a perfect type of application to
leverage AJAX capabilities.I will collapse all of the current web pages into a single rich page with dynamic and asynchronous updates of stock prices, user holdings, buys/sells, etc.
I plan to leverage the DoJo AJAX toolkit which is being pulled into Apache MyFaces.The basic architecture would look like: browser -REST---DayTrader
SOAPDayTrader--- Java --- DayTrader (dojo libs,proxy servlet Web services J2EE App _javascript_)soap/rest transform
|--GERONIMO---| There are several variations to this to pursue for performance comparison. Any feedback? Stan.

[jira] Commented: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.

2006-08-09 Thread David Jencks (JIRA)

[ 
http://issues.apache.org/jira/browse/XBEAN-36?page=comments#action_12426997 ] 

David Jencks commented on XBEAN-36:
---

I _think_ that some jdk 1.5 specific code was installed in this patch -- at 
least new IllegalArgumentException(String, Throwable)

Do we aim to preserve jdk 1.4 support?

 [RTC] Support annotating properties with the ProperyEditor that should be 
 used when wiring in the value.
 

 Key: XBEAN-36
 URL: http://issues.apache.org/jira/browse/XBEAN-36
 Project: XBean
  Issue Type: New Feature
  Components: spring
Reporter: Hiram Chirino
 Assigned To: Hiram Chirino
 Fix For: 2.6

 Attachments: XBEAN-36.patch


 This patch allows you to configure a PropertyEditor for any property.  For 
 example, if you annotate a property as follows:
/**
 * Sets the amount of beer remaining in the keg (in ml)
 * 
 * @org.apache.xbean.Property 
 propertyEditor=org.apache.xbean.spring.example.MilliLittersPropertyEditor
 * @param remaining
 */
 public void setRemaining(long remaining) {
 this.remaining = remaining;
 }
 Then when you configure the value of the 'remaining' property in xbean then 
 the MilliLittersPropertyEditor will be used to convert the string value to a 
 long.  In the test case, our MilliLittersPropertyEditor can handle converting 
 different units of measurement to ml.  For example:
 beans xmlns:x=http://xbean.apache.org/schemas/pizza;
   x:keg id=ml1000 remaining=1000 ml/
   x:keg id=pints5 remaining=5 pints/
   x:keg id=liter20 remaining=20 liter/
   x:keg id=empty remaining=0/
 /beans

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: soap-binding sample error

2006-08-09 Thread ajayk_goel


Thanks a lot!
-- 
View this message in context: 
http://www.nabble.com/soap-binding-sample-error-tf2079610.html#a5731560
Sent from the ServiceMix - Dev forum at Nabble.com.

Re: DayTrader with an AJAX based Web interface

Awesome :)

Unfortunately it doesn't do well with Safari but I hit it from a Windows IE box
and it looks great.

Your going to force us to start making some decisions on how to restructure the beast in terms of
the config and J2EE componentry going forward. Would you be ammenable to sending in the code and we
can put it in the sandbox to play with.

Other items for consideration is to add Spring support as well as EJB 3.0
support.

Looks excellent.

Thanks!

Christopher Blythe wrote:

All,

Here's a first pass at a new Web 2.0, AJAX-based, Web interface for
DayTrader! Take a look at and let me know what you think:

http://porky.hogstrom.org:8080/dojo_trader/daytrader.html

FYI - I highly suggest using Firefox or Mozzilla to view this. Also, thanks
to Matt Hogstrom for his assistance.

This is merely a first pass that provides all of the operational
features of

DayTrader classic, but also leverages the various javascript libraries
(widget, io, storage, etc.) within the Dojo toolkit to provide a better
user

experience. Eventually, I would like for this to serve as an addition to
DayTrader 2.0 and would like feedback and other contributions on how we can
evolve DayTrader to look less like a traditional browser-based,
click-and-wait type application and more like a stand-alone app. I am by no
means a javascript or CSS expert, so any help, recommendations, etc. would
be gratefully appreciated...

Thanks...

Chris

On 3/16/06, Aaron Mulder [EMAIL PROTECTED] wrote:

That definitely sounds like an attractive thing to benchmark to me!
As with the persistence options, etc. I think it would be best to be
able to run it both ways and see what you get with a traditional web
interface and compare that to an AJAX-ified interface.

Thanks,
Aaron

On 3/16/06, J. Stan Cox [EMAIL PROTECTED] wrote:
Geronimos,

I've worked on the Trade benchmark in the past that has been donated
to Geronimo and is now known as DayTrader. I think it will grow and
flourish in the open source environment and become a nice showcase for
Geronimo's performance and capabilities.

I'm interested in adding a rich, AJAX based Web interface to DayTrader
for performance research. DayTrader is a perfect type of
application to

leverage AJAX capabilities. I will collapse all of the current web
pages into a single rich page with dynamic and asynchronous updates of
stock prices, user holdings, buys/sells, etc.

I plan to leverage the DoJo AJAX toolkit which is being pulled into
Apache MyFaces. The basic architecture would look like:

browser -REST- -- DayTrader
SOAP DayTrader --- Java --- DayTrader
(dojo libs,proxy
servlet Web services J2EE App
javascript)soap/rest transform

|--GERONIMO ---|

There are several variations to this to pursue for performance
comparison.

Any feedback?

Stan.

[jira] Commented: (XBEAN-31) [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build

2006-08-09 Thread David Jencks (JIRA)

[ 
http://issues.apache.org/jira/browse/XBEAN-31?page=comments#action_12427004 ] 

David Jencks commented on XBEAN-31:
---

Matt's version of the patch applies and builds for me, I'll repeat my +1

 [RTC] it would be great if the m2 plugin would automatically add the XSD and 
 .xsd.html files as artifacts into the build
 

 Key: XBEAN-31
 URL: http://issues.apache.org/jira/browse/XBEAN-31
 Project: XBean
  Issue Type: Wish
  Components: maven-plugin
Reporter: james strachan
 Assigned To: Guillaume Nodet
 Fix For: 2.6

 Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff


 So that the XSD and HTML reference would be automatically deployed into the 
 m2 repository. 
 See the attach-artifact for how to do it manually in each POM. But given how 
 many projects are using the m2 plugin it would simplify our lives if the m2 
 plugin did this for us
 http://mojo.codehaus.org/build-helper-maven-plugin/howto.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: DayTrader with an AJAX based Web interface

2006-08-09 Thread Jason Dillon

This is definitely not happy in Safari :-( ... and when run from Camino it popped up a little dialog saying that the script was unresponsive, but telling it to continue eventually did display the UI.--jasonOn Aug 9, 2006, at 11:29 AM, Christopher Blythe wrote:All,  Here's a first pass at a new Web 2.0, AJAX-based, Web interface for DayTrader! Take a look at and let me know what you think:   http://porky.hogstrom.org:8080/dojo_trader/daytrader.html  FYI - I highly suggest using Firefox or Mozzilla to view this. Also, thanks to Matt Hogstrom for his assistance.  This is merely a first pass that provides all of the operational features of DayTrader "classic", but also leverages the various _javascript_ libraries (widget, io, storage, etc.) within the Dojo toolkit to provide a better user experience. Eventually, I would like for this to serve as an addition to DayTrader 2.0 and would like feedback and other contributions on how we can evolve DayTrader to look less like a traditional browser-based, click-and-wait type application and more like a stand-alone app. I am by no means a _javascript_ or CSS expert, so any help, recommendations, etc.  would be gratefully appreciated...   Thanks...

Tagging the 2.1.1 release of OpenEJB