Re: activemq architecture with jboss
On 8/16/06, masien [EMAIL PROTECTED] wrote: Hi all, Execuse me but i am new in JMS and ActiveMQ... I'd like to create an architecture with a client that send messages to 2 brokers (in cluster) and a MDB that consume the messages. Must I use JBOSS for use MDB? MDBs are supported by all J2EE application servers so you can take your pick there. Also there are Message Driven POJOs if you don't want to go the J2EE route http://jencks.org/Message+Driven+POJOs In this case, must i have two instance of Jboss in order to avoid the single point of failure? That is a good road??? Help me...it is very important. Whether you use 1 broker or 2 in a cluster - I recommend running multiple JVMs preferably on different boxes of the JMS clients (the producers and consumers). Whether you use Tomcat or JBoss or just a regular JVM is your call, whatever you are comfortable with. -- James --- http://radio.weblogs.com/0112098/
Re: activemq architecture with jboss
When I configure two instance of JBOSS...must to point each instance to each ActiveMQ broker ? P.S. The client producer is on another jvm and it send messages to brokers that are on other two virtual machine. Max -- View this message in context: http://www.nabble.com/activemq-architecture-with-jboss-tf2118066.html#a5848392 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: activemq architecture with jboss
On 8/17/06, masien [EMAIL PROTECTED] wrote: When I configure two instance of JBOSS...must to point each instance to each ActiveMQ broker ? P.S. The client producer is on another jvm and it send messages to brokers that are on other two virtual machine. If you have 2 JBoss servers hosting MDBs then you might as well just run a single ActveMQ broker separately and have everyone talk to the same broker for simplicity. If you want full HA you might then consider running that broker as a pair of master/slaves. http://incubator.apache.org/activemq/masterslave.html -- James --- http://radio.weblogs.com/0112098/
Re: Queue hogging by a single consumer.
Hi James, Thanks for your response. Are you trying to implement request-response with A, B, C making requests on Z and getting the response? Or can A, B, C process any message from Z? Exactly the first case. A, B, C making requests on Z and getting the response from Z I'm not sure if your issue is that say A doesn't see the responses for its request (if thats the case use either 3 queues, use temporary queues for the responses or use a selector and a correlationID on the request response) - or is it that you have a small number of responses from Z and they are being hogged by one consumer - in which case setting a small prefetch and a round robin dispatch policy will fix this. Its that, A doesn't see the responses for its requests made. I would really appreciate if I can get some help stuff on - 1) Creating, destroying and maintaining data in temporary queues. 2) Setting selector and correlationID in messages. On 8/17/06, Naveen Rawat [EMAIL PROTECTED] wrote: Hi all :) I am working with the binary version of ActiveMQ 4.0 broker and trying out the openwire cpp apis for asynchronous messaging. [https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0/openw ire-cpp] I wonder if I m resurrecting the mummies of issues already burnt. I am trying out having 3 consumers A, B and C listening on the same queue. What I am trying to do is - A, B, C sending on Q1, and consuming Z's response on Q2 Consumer Z listening on Q1, responding back on Q2. like this - A/B/CQ1ZQ2A/B/C Listening/responding to a single consumer is working well at present. BUT broker is spoofing up the responses from Z to the simultaneous consumers (either 2 or all three). Response for one consumer (A) is going to any of the other consumer (B/C). Same is happening for other consumers. Being prefetch size preset to 1000, the consumer that first manages session with the broker on a queue is getting all the messages (and if it gets terminated, the following one hogs the all and so on.) . As I m at presently testing, setting prefetch size to less (say 1), even dont solves the purpose as not giving it frequest quick requests (man Vs machine). Moreover as the hogging consumer is reading and acknowledging all the responses, the prefetch size of even 1 is not surpassed. I tried out with no success the way of grid processing of messages (using MessageGroups) as suggested in http://activemq.org/site/how-do-i-preserve-order-of-messages.html Code relevant of this is as follows - [A/B/C producer = session-createProducer(Q1) ; producer-setPersistent(true) ; message = session-createBytesMessage() ; message-setJMSXGroupID(cheese) ; message-writeString(Hello World) ; producer-send(message); .] [ .Z ' s OnMessage(message)... pstring NGid; NGid = message-getJMSXGroupID(); producer = session-createProducer(Q2) ; producer-setPersistent(true) ; reqMessage = session-createBytesMessage() ; reqMessage-setJMSXGroupID(NGid-c_str() ); reqMessage-writeString(R E C E I V E D) ;//response string producer-send(reqMessage); .] Is there anymore needed in the code that I m loosing? I come to know that there are certain issues yet not resolved pertaining to the prefetch buffer initial size. Correct me please. Will manipulation of prefetch buffer size help my cause? Please suggest a way otherwise. THANKS IN ADVANCE Regards, Navin
Re: Queue hogging by a single consumer.
On 8/17/06, Naveen Rawat [EMAIL PROTECTED] wrote: Hi James, Thanks for your response. Are you trying to implement request-response with A, B, C making requests on Z and getting the response? Or can A, B, C process any message from Z? Exactly the first case. A, B, C making requests on Z and getting the response from Z I'm not sure if your issue is that say A doesn't see the responses for its request (if thats the case use either 3 queues, use temporary queues for the responses or use a selector and a correlationID on the request response) - or is it that you have a small number of responses from Z and they are being hogged by one consumer - in which case setting a small prefetch and a round robin dispatch policy will fix this. Its that, A doesn't see the responses for its requests made. I would really appreciate if I can get some help stuff on - 1) Creating, destroying and maintaining data in temporary queues. 2) Setting selector and correlationID in messages. Details here http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html for 1) just call session.createTemporaryQueue() and set that queue on the Message.setJMSReplyTo() property so that services can reply to your temporary queue. They are deleted when A terminates so there's no issue with maintaining data. for 2) just add a JMSCorrelationID() to the request messages you send as requests. You can then use a selector such as JMSCorrelationID = 'abc' on the consumer for responses so that responses are filtered to only return A's results etc The contract of Z whichever option you go with is the to copy the JMSCorrelationID property from the request to the response message and send the response message to the request.getJMSReployTo() destination -- James --- http://radio.weblogs.com/0112098/
Re: Queue hogging by a single consumer.
Thanks James. Thanks for the response I will try out your suggestions and get back to you soon. Hi James, Thanks for your response. Are you trying to implement request-response with A, B, C making requests on Z and getting the response? Or can A, B, C process any message from Z? Exactly the first case. A, B, C making requests on Z and getting the response from Z I'm not sure if your issue is that say A doesn't see the responses for its request (if thats the case use either 3 queues, use temporary queues for the responses or use a selector and a correlationID on the request response) - or is it that you have a small number of responses from Z and they are being hogged by one consumer - in which case setting a small prefetch and a round robin dispatch policy will fix this. Its that, A doesn't see the responses for its requests made. I would really appreciate if I can get some help stuff on - 1) Creating, destroying and maintaining data in temporary queues. 2) Setting selector and correlationID in messages. Details here http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html for 1) just call session.createTemporaryQueue() and set that queue on the Message.setJMSReplyTo() property so that services can reply to your temporary queue. They are deleted when A terminates so there's no issue with maintaining data. for 2) just add a JMSCorrelationID() to the request messages you send as requests. You can then use a selector such as JMSCorrelationID = 'abc' on the consumer for responses so that responses are filtered to only return A's results etc The contract of Z whichever option you go with is the to copy the JMSCorrelationID property from the request to the response message and send the response message to the request.getJMSReployTo() destination Regards, Navin
RE: How To remove Queue from the session
I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default), in C++ . How to remove/deattached a queue from the session without closeing connection from the sender/reveiver side?. is it possible? Close the Consumer or Producer and delete it would be my guess. - Timothy A. Bish Sensis Corporation - -Original Message- From: Arshad Ahamad [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 7:36 AM To: activemq-dev@geronimo.apache.org; activemq-users@geronimo.apache.org Subject: How To remove Queue from the session Hi all, Thanks Arashad Ahamad
How To remove Queue from the session
Hi all, I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default), in C++ . How to remove/deattached a queue from the session without closeing connection from the sender/reveiver side?. is it possible? Thanks Arashad Ahamad
Re: How To remove Queue from the session
Hi Bish, When I use session-close() API then the following error comes up.. [FAILED] Message content has been corrupted and this does not remove the queue from the receiver side is there any other API for that please tell me. I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default), in C++ . How to remove/deattached a queue from the session without closeing connection from the sender/reveiver side?. is it possible? Close the Consumer or Producer and delete it would be my guess. How to close consumer/producer(what is the API)? Thanks Arashad Ahamad
[jira] Created: (AMQ-882) TopicPublisher.publish(topicSession.createTextMessage(Hello World) hangs and throws a JMSException
TopicPublisher.publish(topicSession.createTextMessage(Hello World) hangs and
throws a JMSException
Key: AMQ-882
URL: https://issues.apache.org/activemq/browse/AMQ-882
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 4.0.1
Environment: Server: Suse Linux 2.6.5-7.244-smp, JDK 1.5.0_07
Client: Windows XP SP2, JDK 1.5.0_06
Reporter: Kai Pruente
Scenario:
ActiveMQ and the publisher process running on the same server.
Several clients are running on several Windows-XP clients
Publisher code:
{code}
// initializing
connection = msgFactory.createTopicConnection();
connection.setExceptionListener(new JMSExceptionListener());
connection.start();
topicSession = connection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
topic = topicSession.createTopic(MFS_LOCATION_CHANGE_EVENT_TOPIC);
publisher = topicSession.createPublisher(topic);
publisher.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
[...]
// sending several times with the same topic
try {
publisher.publish(topicSession.createTextMessage(location.getName()));
} catch (JMSException e) {
log.fatal(Problems during informing Workplace topic: + location.getName(),
e);
[...]
{code}
Subscriber code:
{code}
topicConnection = msgFactory.createTopicConnection();
topicConnection.start();
topicConnection.setExceptionListener(new JMSExceptionListener(listeners, this));
topicSession = topicConnection.createTopicSession(false,
Session.AUTO_ACKNOWLEDGE);
Topic topic =
topicSession.createTopic(EventSender.MFS_LOCATION_CHANGE_EVENT_TOPIC);
topicSubscriber = topicSession.createSubscriber(topic);
topicSubscriber.setMessageListener(new MessageListener() {
public void onMessage(Message message) {
if (message instanceof TextMessage) {
[...]
topicConnection.start();
{code}
After some thound of messages publish hangs for more than 1 minute and then
throws a JMSException (see logs below). After searching in ActiveMQ mailing
lists I changed the broker url of the publisher from:
* tcp://arvwms:61616
to
*
tcp://arvwms:61616?soTimeout=2000connectionTimeout=1socketBufferSize=1024wireFormat.maxInactivityDuration=0
This works some days fine, but now we get the exceptions again.
Is this a problem between topic publisher and ActiveMQ or could it be also a
problem between ActiveMQ and topic subscriber? If it is real a problem between
publisher and ActiveMQ it can't be a network problem, becuase it is the same
server.
This problems occur about 10 times the day. With the exception and losing of 10
messages the day I could live, but the hanging about 1 minute is terrible for
our application.
The Exception:
{code}
DEBUG 2006-08-17 12:45:53.738 portConfirmationDefaultHandler :-: -
handle telegram: [EMAIL
PROTECTED],loadUnit=01900,lastLocation=SCS_CS,weight=null,orientation=0,infoType=COMPLETE,wmsID=1039340,reason=OK]
FATAL 2006-08-17 12:47:12.534 EventSender:-: -
Problems during informing Workplace topic:SCS_CS
javax.jms.JMSException: Broken pipe
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:57)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1094)
at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1553)
at
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:462)
at
org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:356)
at
org.apache.activemq.ActiveMQTopicPublisher.publish(ActiveMQTopicPublisher.java:128)
at
com.ssn.acx.extensions.logistics.mfsadapter.event.EventSender.sendLocationChangeEvent(EventSender.java:150)
at
com.ssn.acx.extensions.logistics.mfsadapter.MFSTransactionWithSendingTrigger.commit(MFSTransactionWithSendingTrigger.java:109)
at
com.ssn.acx.core.common.transaction.GlobalTransactionImpl.commit(GlobalTransactionImpl.java:198)
at
com.ssn.acx.core.common.adapterservice.TelegramDispatcher.handleTelegram(TelegramDispatcher.java:306)
at
com.ssn.acx.core.common.adapterservice.TelegramDispatcher.dispatch(TelegramDispatcher.java:180)
at
com.ssn.acx.core.common.adapterservice.AbstractCollector.dispatch(AbstractCollector.java:81)
at
com.ssn.acx.api.common.adapterservice.TriggeredCollector.dispatch(TriggeredCollector.java:87)
at
com.ssn.acx.core.logistics.mfsadapter.MFSCollector.collectTelegrams(MFSCollector.java:122)
at
com.ssn.acx.core.logistics.mfsadapter.WakeUpListener.run(WakeUpListener.java:142)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at
RE: How To remove Queue from the session
When I use session-close() API then the following error comes up.. [FAILED] Message content has been corrupted Sounds like a possible bug in the openwire-cpp code. IF you can write a small test app that demonstrates the problem you could submit an issue and hopefully the openwire-cpp guys can take a look at it. and this does not remove the queue from the receiver side is there any other API for that please tell me. - Timothy A. Bish Sensis Corporation - -Original Message- From: Arshad Ahamad [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 8:02 AM To: activemq-dev@geronimo.apache.org; activemq-users@geronimo.apache.org Subject: Re: How To remove Queue from the session Hi Bish, When I use session-close() API then the following error comes up.. [FAILED] Message content has been corrupted and this does not remove the queue from the receiver side is there any other API for that please tell me. I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default), in C++ . How to remove/deattached a queue from the session without closeing connection from the sender/reveiver side?. is it possible? Close the Consumer or Producer and delete it would be my guess. How to close consumer/producer(what is the API)? Thanks Arashad Ahamad
Re: How To remove Queue from the session
On 8/17/06, Arshad Ahamad [EMAIL PROTECTED] wrote: Hi Bish, No no. I am not talking about the temporary queue, I am asking about the nameing queue. I don't follow what you're asking. FWIW queues only really exist on the broker (they are not really associated with a client or session). The only way to remove queues is via JMX on the broker -- James --- http://radio.weblogs.com/0112098/
Re: Queue hogging by a single consumer.
On 8/17/06, Naveen Rawat [EMAIL PROTECTED] wrote: Great James Your suggestion is working. A major hurdle seems solved. A little query down there. Hi James, Thanks for your response. Are you trying to implement request-response with A, B, C making requests on Z and getting the response? Or can A, B, C process any message from Z? Exactly the first case. A, B, C making requests on Z and getting the response from Z I'm not sure if your issue is that say A doesn't see the responses for its request (if thats the case use either 3 queues, use temporary queues for the responses or use a selector and a correlationID on the request response) - or is it that you have a small number of responses from Z and they are being hogged by one consumer - in which case setting a small prefetch and a round robin dispatch policy will fix this. Its that, A doesn't see the responses for its requests made. I would really appreciate if I can get some help stuff on - 1) Creating, destroying and maintaining data in temporary queues. 2) Setting selector and correlationID in messages. Details here http://incubator.apache.org/activemq/how-should-i-implement-request-response-with-jms.html for 1) just call session.createTemporaryQueue() and set that queue on the Message.setJMSReplyTo() property so that services can reply to your temporary queue. They are deleted when A terminates so there's no issue with maintaining data. for 2) just add a JMSCorrelationID() to the request messages you send as requests. You can then use a selector such as JMSCorrelationID = 'abc' on the consumer for responses so that responses are filtered to only return A's results etc I went for this (2nd) one. Even though now a result is obtained, I would like to ask which one approach is more favoured by you. Is it the temporary queues overhead matter that makes 2nd score over 1st? Any other reason please tell. The main difference is, do you want the response to be persistent. e.g. if A dies and comes back again later - do you want it to resume processing old results? In which case use a persistent queue and correlation IDs. If the responses are transient then use a temporary queue so the old messages get discarded by the broker when A dies. -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (AMQ-865) C# Client's Listener doesn't receive messages if you don't explicitly call Subscribe
[
https://issues.apache.org/activemq/browse/AMQ-865?page=comments#action_36801 ]
james strachan commented on AMQ-865:
Here's another test case which seems to show a similar issue...
http://www.nabble.com/Durable-topic-subscription-needs-pump-primed.-tf2117517.html#a5852831
using System;
using System.Collections.Generic;
using System.Text;
using NUnit.Framework;
using NUnit.Extensions;
using ActiveMQ;
using NMS;
using ActiveMQ.Commands;
using System.Threading;
namespace ActiveMQDurableTest
{
[TestFixture]
public class DurableTest
{
private static string TOPIC = TestTopic;
private static String URI = tcp://localhost:61616;
private static String CLIENT_ID = DurableClientId;
private static String CONSUMER_ID = ConsumerId;
private static ConnectionFactory FACTORY = new ConnectionFactory(new
Uri(URI));
private int count = 0;
public void RegisterDurableConsumer()
{
using (IConnection connection = FACTORY.CreateConnection())
{
connection.ClientId = CLIENT_ID;
connection.Start();
using (ISession session =
connection.CreateSession(AcknowledgementMode.DupsOkAcknowledge))
{
ITopic topic = session.GetTopic(TOPIC);
IMessageConsumer consumer =
session.CreateDurableConsumer(topic, CONSUMER_ID, 2 1, false);
consumer.Dispose();
}
connection.Stop();
}
}
public void SendPersistentMessage()
{
using (IConnection connection = FACTORY.CreateConnection())
{
connection.Start();
using (ISession session =
connection.CreateSession(AcknowledgementMode.DupsOkAcknowledge))
{
ITopic topic = session.GetTopic(TOPIC);
ActiveMQTextMessage message = new
ActiveMQTextMessage(Hello);
message.NMSPersistent = true;
message.Persistent = true;
IMessageProducer producer = session.CreateProducer();
producer.Send(topic, message);
producer.Dispose();
}
connection.Stop();
}
}
[Test]
public void TestMe()
{
count = 0;
RegisterDurableConsumer();
SendPersistentMessage();
using (IConnection connection = FACTORY.CreateConnection())
{
connection.ClientId = CLIENT_ID;
connection.Start();
using (ISession session =
connection.CreateSession(AcknowledgementMode.DupsOkAcknowledge))
{
ITopic topic = session.GetTopic(TOPIC);
IMessageConsumer consumer =
session.CreateDurableConsumer(topic, CONSUMER_ID, 2 1, false);
consumer.Listener += new
MessageListener(consumer_Listener);
/// Don't know how else to give the system enough time.
///
Thread.Sleep(5000);
Assert.AreEqual(0, count);
Console.WriteLine(Count = + count);
SendPersistentMessage();
Thread.Sleep(5000);
Assert.AreEqual(2, count);
Console.WriteLine(Count = + count);
consumer.Dispose();
}
connection.Stop();
}
}
/// summary
///
/// /summary
/// param name=message/param
private void consumer_Listener(IMessage message)
{
++count;
- Hide quoted text -
}
}
}
C# Client's Listener doesn't receive messages if you don't explicitly call
Subscribe
Key: AMQ-865
URL: https://issues.apache.org/activemq/browse/AMQ-865
Project: ActiveMQ
Issue Type: Bug
Components: NMS (C# client)
Environment: Windows XP, VS 2005, ActiveMQ 4.0.1
Reporter: Denis Abramov
Easiest way to reproduce the bug would be to start the consumer using the
following code and then AFTER the consumer starts, start some producer
(either java or C#) and you will notice that the consumer will not get any
messages (through trial and error I found that calling Receive() on the
consumer at least once will make you lose a message but the listener will
kick back in):
using System;
using ActiveMQ;
using ActiveMQ.Commands;
using NMS;
namespace JMSClient
{
/// summary
/// Summary description for Class1.
/// /summary
class Class1
{
/// summary
/// The main entry point for the application.
/// /summary
[STAThread]
Global JNDI
Earlier this week, David convinced me to help him get the JPA entity manager factories mapped into JNDI. And, that was the easy part, he also wanted it to work in G 1.1. Today, I finally got it working and wrote up some very rudimentary instruction on how to manually install it (need to figure out how to automate this) here: http://cwiki.apache.org/confluence/display/GMOxSBOX/Global+JNDI+Plugin Anyway, while writing this code I ended up writing a thread safe context which althought it isn't publicly modifiable can internally modify itself. I also wrote a subclass of this that watches the kernel for Contexts and adds them to the global name space. It occurred to me that with this code plus the code Krishnakumar Manu wrote in GERONIMO-2153 we may be able to have a complete global jndi plugin that can run in G 1.1. I'm going to try this over the next few days and let you'll if it works out. -dain
Queue hogging by a single consumer.
Hi all :) I am working with the binary version of ActiveMQ 4.0 broker and trying out the openwire cpp apis for asynchronous messaging. [https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0/openw ire-cpp] I wonder if I m resurrecting the mummies of issues already burnt. I am trying out having 3 consumers A, B and C listening on the same queue. What I am trying to do is - A, B, C sending on Q1, and consuming Z's response on Q2 Consumer Z listening on Q1, responding back on Q2. like this - A/B/CQ1ZQ2A/B/C Listening/responding to a single consumer is working well at present. BUT broker is spoofing up the responses from Z to the simultaneous consumers (either 2 or all three). Response for one consumer (A) is going to any of the other consumer (B/C). Same is happening for other consumers. Being prefetch size preset to 1000, the consumer that first manages session with the broker on a queue is getting all the messages (and if it gets terminated, the following one hogs the all and so on.) . As I m at presently testing, setting prefetch size to less (say 1), even dont solves the purpose as not giving it frequest quick requests (man Vs machine). Moreover as the hogging consumer is reading and acknowledging all the responses, the prefetch size of even 1 is not surpassed. I tried out with no success the way of grid processing of messages (using MessageGroups) as suggested in http://activemq.org/site/how-do-i-preserve-order-of-messages.html Code relevant of this is as follows - [A/B/C producer = session-createProducer(Q1) ; producer-setPersistent(true) ; message = session-createBytesMessage() ; message-setJMSXGroupID(cheese) ; message-writeString(Hello World) ; producer-send(message); .] [ .Z ' s OnMessage(message)... pstring NGid; NGid = message-getJMSXGroupID(); producer = session-createProducer(Q2) ; producer-setPersistent(true) ; reqMessage = session-createBytesMessage() ; reqMessage-setJMSXGroupID(NGid-c_str() ); reqMessage-writeString(R E C E I V E D) ; //response string producer-send(reqMessage); .] Is there anymore needed in the code that I m loosing? I come to know that there are certain issues yet not resolved pertaining to the prefetch buffer initial size. Correct me please. Will manipulation of prefetch buffer size help my cause? Please suggest a way otherwise. HELP ME.. THANKS IN ADVANCE Regards, Navin
[jira] Assigned: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
[ https://issues.apache.org/activemq/browse/AMQ-877?page=all ]
Rob Davies reassigned AMQ-877:
--
Assignee: Rob Davies
Patch: refactoring to allow alternative (using different storage interface)
Destinations implementations.
-
Key: AMQ-877
URL: https://issues.apache.org/activemq/browse/AMQ-877
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 4.x
Reporter: Maxim Fateev
Assigned To: Rob Davies
Attachments: destinationFactoryActiveMQPatch.txt
We were looking at alternate message persistence mechanisms that can co-exist
in current ActiveMQ code base and we are thinking of a mechanism that is
somewhat incompatible with the current MessageStore and PersistenceAdapter
APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
change as the PersistenceAdapter and MessageStore interfaces are referenced
directly by the RegionBroker and by both the Queue and Topic region
implementations. Therefore, we are proposing a relatively small backwards
compatible refactoring of the broker code that would eliminate all
dependencies on the PersistenceAdapter and MessageStore interfaces from those
classes that do not use them directly. This refactoring would also allow
creation of a custom Destination implementation that may use an alternative
persistence mechanism on a destination by destination basis (which is exactly
what we need to do).
The main idea behind the refactoring is to replace many references to
PersistenceAdapter with a new interface: DestinationFactory:
public abstract class DestinationFactory {
abstract public Destination createDestination(ConnectionContext
context, ActiveMQDestination destination, DestinationStatistics
destinationStatistics) throws Exception;
abstract public Set getDestinations();
abstract public SubscriptionInfo[]
getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
abstract public long getLastMessageBrokerSequenceId() throws
IOException;
abstract public void setRegionBroker(RegionBroker regionBroker);
}
Note that DestinationFactory doesn't mandate any specific persistence
mechanism. The classes that would reference it instead of PersistenceAdapter
are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
AbstractRegion.createDestination method would be changed from abstract to an
implementation that uses DestinationFactory to create a destination.
BrokerService could be changed to use DestinationFactory if one is
provided. If none is provided, it will create a DestinationFactory
implementation that instantiates Queue and Topic using PersistenceAdapter as
it does currently. Hence, full backwards compatibility will be maintained.
Patch is attached.
--
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: Issue for 4.x version is not being looked at
Somebody needed to take ownership and then assign a fix schedule for it (done) cheers, Rob On 17 Aug 2006, at 02:01, Fateev, Maxim wrote: I've submitted a patch at Friday against 4.x: http:// issues.apache.org/activemq/browse/AMQ-877 But it doesn't show up in the list of outstanding issues for 4.x (https://issues.apache.org/activemq/secure/IssueNavigator.jspa? mode=hiderequestId=11102). Should I resubmit it against 4.1 to get it looked at? Thanks, Maxim.
[jira] Updated: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
[ https://issues.apache.org/activemq/browse/AMQ-877?page=all ]
Rob Davies updated AMQ-877:
---
Fix Version/s: 4.1
Patch: refactoring to allow alternative (using different storage interface)
Destinations implementations.
-
Key: AMQ-877
URL: https://issues.apache.org/activemq/browse/AMQ-877
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 4.x
Reporter: Maxim Fateev
Assigned To: Rob Davies
Fix For: 4.1
Attachments: destinationFactoryActiveMQPatch.txt
We were looking at alternate message persistence mechanisms that can co-exist
in current ActiveMQ code base and we are thinking of a mechanism that is
somewhat incompatible with the current MessageStore and PersistenceAdapter
APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a
change as the PersistenceAdapter and MessageStore interfaces are referenced
directly by the RegionBroker and by both the Queue and Topic region
implementations. Therefore, we are proposing a relatively small backwards
compatible refactoring of the broker code that would eliminate all
dependencies on the PersistenceAdapter and MessageStore interfaces from those
classes that do not use them directly. This refactoring would also allow
creation of a custom Destination implementation that may use an alternative
persistence mechanism on a destination by destination basis (which is exactly
what we need to do).
The main idea behind the refactoring is to replace many references to
PersistenceAdapter with a new interface: DestinationFactory:
public abstract class DestinationFactory {
abstract public Destination createDestination(ConnectionContext
context, ActiveMQDestination destination, DestinationStatistics
destinationStatistics) throws Exception;
abstract public Set getDestinations();
abstract public SubscriptionInfo[]
getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException;
abstract public long getLastMessageBrokerSequenceId() throws
IOException;
abstract public void setRegionBroker(RegionBroker regionBroker);
}
Note that DestinationFactory doesn't mandate any specific persistence
mechanism. The classes that would reference it instead of PersistenceAdapter
are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the
AbstractRegion.createDestination method would be changed from abstract to an
implementation that uses DestinationFactory to create a destination.
BrokerService could be changed to use DestinationFactory if one is
provided. If none is provided, it will create a DestinationFactory
implementation that instantiates Queue and Topic using PersistenceAdapter as
it does currently. Hence, full backwards compatibility will be maintained.
Patch is attached.
--
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: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
On 8/14/06, Matt Hogstrom [EMAIL PROTECTED] wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) (back from my vacation) Welcome back Alan! I hope Yoko won't mind if you spend some more time working for Geronimo and I am not talking about Yoko the project ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
GERONIMO-2324
So does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don't fully address the problem.(1) Need to be able to provide external individual jar entries to the shared library(2) Need to be able to add additional external classes folder to the shared library(3) Do both without having to modify the server config which requires a server restart, which needs to be avoided. At worst case the shared lib config should need to be recycled.This again I must stress, is a development time scenario to be able to treat Geronimo as a "test environment". I understand the implications of doing this, and agree that this should not be an in-production feature that we should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may not necessarily make sense from a pure runtime perspective but certainly does from a development standpoint.Input appreciated.-sachin
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
Congratulations Guillaume! Anita --- Matt Hogstrom [EMAIL PROTECTED] wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: GERONIMO-2324
Hi Sachin, I apologize in advance if I say anything exceedingly ignorant and/or foolish... Given that this functionality is meant for a relatively specific use case (utilizing Geronimo as a developer's test environment), and that having this functionality in a production environment is generally considered undesirable, would it be possible to implement this functionality within an external plugin which wouldn't normally be present in a Production or QA environment, but which could be installed in a development environment? Ian It's better to be hated for who you are than loved for who you're not Ian D. Stewart Distributed Computing Engineer II DSS eCommerce Engineering JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Sachin Patel [EMAIL PROTECTED] omTo Sent by: Sachin dev@geronimo.apache.org Patel cc [EMAIL PROTECTED] mSubject GERONIMO-2324 08/17/2006 08:06 AM Please respond to [EMAIL PROTECTED] he.org So does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don't fully address the problem. (1) Need to be able to provide external individual jar entries to the shared library (2) Need to be able to add additional external classes folder to the shared library (3) Do both without having to modify the server config which requires a server restart, which needs to be avoided. At worst case the shared lib config should need to be recycled. This again I must stress, is a development time scenario to be able to treat Geronimo as a test environment. I understand the implications of doing this, and agree that this should not be an in-production feature that we should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may not necessarily make sense from a pure runtime perspective but certainly does from a development standpoint. Input appreciated. -sachin - This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
[jira] Commented: (AMQ-867) JMX Management Console Not Working As Documented
[ https://issues.apache.org/activemq/browse/AMQ-867?page=comments#action_36799 ] Douglas A. Seifert commented on AMQ-867: Willing to close this as the workaround works. The shutdown (and others) script works as well, but if you change the JMX port in the activemq xml configuration file, you need to use the --jmxurl service:jmx:rmi:///jndi/rmi://localhost:NEWPORT/jmxrmi arguments to all scripts. Would be nice if the scripts could figure this out from the xml configuration. JMX Management Console Not Working As Documented Key: AMQ-867 URL: https://issues.apache.org/activemq/browse/AMQ-867 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1, 4.0.2 Environment: Linux nuk 2.6.15-23-amd64-generic #1 SMP PREEMPT Tue May 23 13:45:47 UTC 2006 x86_64 GNU/Linux Reporter: Douglas A. Seifert Starting in 4.0.1 and continuing in a snapshot 4.0.2 release, the ActiveMQ JMX management console is not working as advertised. In version 4.0, I would see the following message logged to the console when starting activemq: INFO ManagementContext - JMX consoles can connect to service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi In Version 4.0.1 and higher, I no longer see this message. When trying to connect to the broker using the jconsole program, in versions 4.0.1 and higher, the following command does not work (get Connection failed message). jconsole service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi However, in 4.0, it does work. With 4.0.1 and higher, I am able to execute jconsole with no arguments and pick the activemq jvm from the dialog that pops up and access the managment mbeans just fine. A symptom of this problem in 4.0.1 and higher is that none of the command line tools in the bin directory work. Here is sample output: [EMAIL PROTECTED]:~/tools/activemq/incubator-activemq-4.0.2/bin$ ./shutdown ACTIVEMQ_HOME: /home/doug/tools/activemq/incubator-activemq-4.0.2 ERROR: java.lang.RuntimeException: Failed to execute stop task. Reason: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] ERROR: java.lang.Exception: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: java.net.ConnectException: Connection refused] With 4.0, all command line tools work as expected. Not sure what is going on here, but something changed in versions 4.0.1 and above. One last note: in 4.0.1 and higher, I uncommented the managementContext tag in the activemq.xml file, but that had no effect. The problem remained as described here. -- 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)
Maybe it's time to ask the incubator PMC to vote on this release ? 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 -- Cheers, Guillaume Nodet
Re: Organization and versioning of specs; a new proposal
I'm ok with dropping it.
-dain
On Aug 16, 2006, at 1:40 PM, Jason Dillon wrote:
I have always been in favor of dropping any uber-jars. They cause
more problems then they are worth.
As for RTC... I am not so sure that this applies really. Its not
going to surprise anyone, its not adding any new code... just
fixing up the poms and moving a few bits around in svn.
But, I can jump though the RTC hoop if that is what the PMC
wants... I think its a waste of time... mostly mine.
--jason
On Aug 16, 2006, at 7:13 AM, Kevan Miller wrote:
On Aug 16, 2006, at 3:56 AM, Jason Dillon wrote:
What is the status on 1.1.1 wrt this change? Can I go ahead and
make these changes?
My reading of Matt's note (which I agree with) is that you should
wait until 1.1.1 has been shipped (unless 1.1.1 runs into an
extended delay in releasing due to administrative matters).
I think this change should follow the RTC process. This is not a
bug fix, not a doc change, etc. It's updating svn and changing the
way we deliver specs -- my read is that it falls under RTC.
You don't mention geronimo-j2ee_1.4_spec (the uber-jar). It's
currently versioned using the top-level pom version. I assume you
plan on adding a geronimoSpecsJ2eeVersion?
Your process for updating the jms spec would be:
cd specs/geronimo-spec-jms
mvn release
cd ../geronimo-spec-j2ee
mvn release
I'm not so sure that this is any better than we have now... I see
two options:
1) drop the uber-jar
2) release all specs simultaneosly (even if they haven't changed)
and all have the same version...
--kevan
--jason
On Aug 12, 2006, at 12:16 AM, Matt Hogstrom wrote:
Jason,
I'm +1 on the change. In order to release 1.1.1 we need to
release an updated version of the J2EE_JAAC specs. I am waiting
for feedback from Geir on some licensing issues as well as a TCK
run that Kevan is doing. That said I'd prefer to wait until the
we cut the 1.1.1 release. If it looks like its going to be
delayed due to the licensing concerns then we should do this
straight away next week.
Since this isn't a code change I agree with Jason's comments on
no review required. Lazy consensus is appropriate here.
Jason Dillon wrote:
A while ago there was talks about independently versioning
specs, and Alan started a reorg branch which gives each spec
module its own trunk+branches+tags...
I have been thinking about this for a while, and with the
recent desire to split off more modules from geronimo/trunk
I've been pondering it even more. What I have come to believe
is that spitting up spec modules into their own trunk+branches
+tags is probably not the best direction for us to head in.
I believe that all of our specs can, and should, share one
trunk... and still have each module specify its own version.
This is very similar to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently.
The top-level pom has a version too, which is independent and
is only changed when there is a major configuration change in
that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check
out and building when you just want all of the specs. If each
spec was in its own trunk, you would need to svn co each one,
then mvn install in each tree, which is a pain.
We also almost never branch specs, they just keep chugging
along, only really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/
trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_,
which we can set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$
{pom.artifactId}
When released, the plugin will svn cp just the module's
directory into a directory under tags, so it will be easy to
see what the released versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own
trunk, and really I think that if we did then it would just
make it more difficult for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change,
which isn't that major, is that the properties which live in
the root pom that control the versions need to be removed... or
rather moved back to the version element of the respective pom.
Comments?
--jason
[jira] Created: (AMQ-883) NMS asynchronous consumption of queued messages
NMS asynchronous consumption of queued messages --- Key: AMQ-883 URL: https://issues.apache.org/activemq/browse/AMQ-883 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Win XP, AMQ 4.0.2 standalone broker, Java message sender (JMS), C# (NMS) receiver Reporter: Bryan Schmidt 1. Several messages are sent to a queue 2. NMS client subscribes 3. Queued messages are not received by NMS client 4. Another message is sent to the queue (while the NMS client is subscribed) 5. NMS client receives all messages Same setup using Java publisher and subscriber behaves properly (queued messages are sent to the subscriber immediately). Editting the AsyncConsumeTest unit test can reproduce the problem and cause the test to fail: In the textMessageSRExample test, move the consumer logic below the producer logic. (I.e. have the message sent to a queue before the consumer subscribes). -- 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: GERONIMO-2324
I feel strongly that is should be stated: Testing is not a relatively specific use case but a natural stage in a lifecycle of an application. You cannot grow into an adult without being a kid first. And how well one were treated as a child, how much warmth one received from parents - defines the adulthood success or failure. This - unmodified - applies to any complex program. Testing and dubugging mode is a first class citizen of an application server and should be treated as such.But Ian made a good point - we don't always want test facilities being available in production environment. And because they are IDE specific - maybe they belong to the IDE adapter? Sort of modified SharedLib GBean installed by IDE integration. And then - the resolver, when looking for resources, asks this bean first before going to startdard Geronimo classloaders? This bean - in turn - maintains a pool of classloaders to dynamically supply IDE resources to other - IDE based - applications? ~olegOn 8/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:Hi Sachin,I apologize in advance if I say anything exceedingly ignorant and/or foolish...Given that this functionality is meant for a relatively specific use case(utilizing Geronimo as a developer's test environment), and that havingthis functionality in a production environment is generally considered undesirable, would it be possible to implement this functionality within anexternal plugin which wouldn't normally be present in a Production or QAenvironment, but which could be installed in a development environment? IanIt's better to be hated for who you arethan loved for who you're notIan D. StewartDistributed Computing Engineer IIDSS eCommerce EngineeringJPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Sachin Patel [EMAIL PROTECTED] omTo Sent by: Sachin dev@geronimo.apache.org Patelcc [EMAIL PROTECTED] mSubject GERONIMO-2324 08/17/2006 08:06 AM Please respond to [EMAIL PROTECTED]he.orgSo does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don'tfully address the problem.(1) Need to be able to provide external individual jar entries to theshared library(2) Need to be able to add additional external classes folder to the shared library(3) Do both without having to modify the server config which requires aserver restart, which needs to be avoided. At worst case the shared libconfig should need to be recycled.This again I must stress, is a development time scenario to be able to treat Geronimo as a test environment. I understand the implications ofdoing this, and agree that this should not be an in-production feature thatwe should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may notnecessarily make sense from a pure runtime perspective but certainly doesfrom a development standpoint.Input appreciated.-sachin -This transmission may contain information that is privileged,confidential, legally privileged, and/or exempt from disclosureunder applicable law.If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, oruse of the information contained herein (including any reliancethereon) is STRICTLY PROHIBITED.Although this transmission andany attachments are believed to be free of any virus or other defect that might affect any computer system into which it isreceived and opened, it is the responsibility of the recipient toensure that it is virus free and no responsibility is accepted byJPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use.If you received this transmission in error, please immediatelycontact the sender and destroy the material in its entirety,whether in electronic or hard copy format. Thank you.
Re: m2 build - validating
inline... --- David Jencks [EMAIL PROTECTED] wrote: On Aug 16, 2006, at 4:33 PM, Bill Dudney wrote: Hi All, i've been using the m2 build for several days now and I've noticed that while it works well there are several details that are still not nailed down. Particularly I've been hitting lots of dependency issues around deployment. So what I've started doing is slogging through each of them one at a time, posting a jira and a patch. It struck me that there are probably similar issues throughout the server WRT the m2 build. I'm open to other methods (and would love to hear of a silver bullet:) but seems to me that we need to basically hit everything in the console and tools and such and make sure it works so we can be sure the dependencies are correct. While I don't think I'll be able to hit 'everything' I'll try to poke on most of the console and the CLI tools and make sure that it 'works'. My plan of attack: 1 - provide patches for the stuff i know about now (tranql/tranql- connector is missing for example from the repository) 2 - finish getting deployment working from the console (data sources, ejb-jar's, wars etc) 3 - poke on the rest of the console 4 - deploy daytrader 5 - anything else anyone comes up with I will be posting bunches of jira's and fixes over the next few days as I work through this stuff (unless someone has a better idea about how to tackle it). This is great that you are taking a look at this. Here are some tips that may help fix dependency problems: 1. The modules use resources2/META-INF/geronimo-dependency.xml files to specify transitive dependencies. We could use a lot more of these. You may find the best solution to a classpath problem is adding one of these. 2. There are often several ways to get a jar into a classloader, such as a) depending on a car, from a car b) depending on a jar from a jar (using geornimo-dependency.xml) c) depending directly on the jar from a car I'd say this is the order of preference 3) It is really important that the builder cars don't start any runtime cars: if you violate this rule the packaging plugin is likely to stop working. You can have 2.a and enforce this rule by using the scope element in the dependency and setting it to scopeclasses/ scope. This means the dependency's classloader will be constructed and available for use but that no services from the car will be started. This might be helpful in adding dependency using 2.a - http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/browser Thanks Anita This is in my experience somewhat nerve wracking and gruesome work, so I really appreciate your taking it on, and I'll do whatever I can to help you with it. thanks david jencks TTFN, -bd- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: m2 build - validating
Oops.., the correct link is : http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL PROTECTED] Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: inline... --- David Jencks [EMAIL PROTECTED] wrote: On Aug 16, 2006, at 4:33 PM, Bill Dudney wrote: Hi All, i've been using the m2 build for several days now and I've noticed that while it works well there are several details that are still not nailed down. Particularly I've been hitting lots of dependency issues around deployment. So what I've started doing is slogging through each of them one at a time, posting a jira and a patch. It struck me that there are probably similar issues throughout the server WRT the m2 build. I'm open to other methods (and would love to hear of a silver bullet:) but seems to me that we need to basically hit everything in the console and tools and such and make sure it works so we can be sure the dependencies are correct. While I don't think I'll be able to hit 'everything' I'll try to poke on most of the console and the CLI tools and make sure that it 'works'. My plan of attack: 1 - provide patches for the stuff i know about now (tranql/tranql- connector is missing for example from the repository) 2 - finish getting deployment working from the console (data sources, ejb-jar's, wars etc) 3 - poke on the rest of the console 4 - deploy daytrader 5 - anything else anyone comes up with I will be posting bunches of jira's and fixes over the next few days as I work through this stuff (unless someone has a better idea about how to tackle it). This is great that you are taking a look at this. Here are some tips that may help fix dependency problems: 1. The modules use resources2/META-INF/geronimo-dependency.xml files to specify transitive dependencies. We could use a lot more of these. You may find the best solution to a classpath problem is adding one of these. 2. There are often several ways to get a jar into a classloader, such as a) depending on a car, from a car b) depending on a jar from a jar (using geornimo-dependency.xml) c) depending directly on the jar from a car I'd say this is the order of preference 3) It is really important that the builder cars don't start any runtime cars: if you violate this rule the packaging plugin is likely to stop working. You can have 2.a and enforce this rule by using the scope element in the dependency and setting it to scopeclasses/ scope. This means the dependency's classloader will be constructed and available for use but that no services from the car will be started. This might be helpful in adding dependency using 2.a - http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/browser Thanks Anita This is in my experience somewhat nerve wracking and gruesome work, so I really appreciate your taking it on, and I'll do whatever I can to help you with it. thanks david jencks TTFN, -bd- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: m2 build - validating
IMO we should not overload the scope mechanism here, but define new configuration elements that allow us to add the additional metadata needed just like how I added classpathPrefix to be used to control the prefix for manifest entries. Then the m2 dependencies would only really be used to control build order for cars. --jason On Aug 17, 2006, at 8:59 AM, anita kulshreshtha wrote: Oops.., the correct link is : http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/% [EMAIL PROTECTED] Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: inline... --- David Jencks [EMAIL PROTECTED] wrote: On Aug 16, 2006, at 4:33 PM, Bill Dudney wrote: Hi All, i've been using the m2 build for several days now and I've noticed that while it works well there are several details that are still not nailed down. Particularly I've been hitting lots of dependency issues around deployment. So what I've started doing is slogging through each of them one at a time, posting a jira and a patch. It struck me that there are probably similar issues throughout the server WRT the m2 build. I'm open to other methods (and would love to hear of a silver bullet:) but seems to me that we need to basically hit everything in the console and tools and such and make sure it works so we can be sure the dependencies are correct. While I don't think I'll be able to hit 'everything' I'll try to poke on most of the console and the CLI tools and make sure that it 'works'. My plan of attack: 1 - provide patches for the stuff i know about now (tranql/tranql- connector is missing for example from the repository) 2 - finish getting deployment working from the console (data sources, ejb-jar's, wars etc) 3 - poke on the rest of the console 4 - deploy daytrader 5 - anything else anyone comes up with I will be posting bunches of jira's and fixes over the next few days as I work through this stuff (unless someone has a better idea about how to tackle it). This is great that you are taking a look at this. Here are some tips that may help fix dependency problems: 1. The modules use resources2/META-INF/geronimo-dependency.xml files to specify transitive dependencies. We could use a lot more of these. You may find the best solution to a classpath problem is adding one of these. 2. There are often several ways to get a jar into a classloader, such as a) depending on a car, from a car b) depending on a jar from a jar (using geornimo-dependency.xml) c) depending directly on the jar from a car I'd say this is the order of preference 3) It is really important that the builder cars don't start any runtime cars: if you violate this rule the packaging plugin is likely to stop working. You can have 2.a and enforce this rule by using the scope element in the dependency and setting it to scopeclasses/ scope. This means the dependency's classloader will be constructed and available for use but that no services from the car will be started. This might be helpful in adding dependency using 2.a - http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/ browser Thanks Anita This is in my experience somewhat nerve wracking and gruesome work, so I really appreciate your taking it on, and I'll do whatever I can to help you with it. thanks david jencks TTFN, -bd- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Move trunk, tags and branches to server/*
Okay, next wednesday, the 23rd, ~midnight it is. I will send email that day in the afternoon and then before and after the move. --jason On Aug 16, 2006, at 7:33 AM, Matt Hogstrom wrote: Jason, I'd suggest Wednesday night midnight (Thursday morning 0001 PT) as most peeps will be sleeping, getting ready to sleep or waking up and we have a Friday. I don't think there is ever going to be a universally good time. Next Wednesday would be my vote as I think 1.1.1 will be completed. Others? Jason Dillon wrote: This is a simple change... but will have a large affect on developers, who will need to checkout again. When is a good time to implement this? --jason On Aug 15, 2006, at 11:18 PM, Guillaume Nodet wrote: +1 On 8/16/06, Jason Dillon [EMAIL PROTECTED] wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason --Cheers, Guillaume Nodet
[jira] Commented: (SM-529) Servicemix-Component's MPSSettingTest.java hangs indefinitely.
[ https://issues.apache.org/activemq/browse/SM-529?page=comments#action_36802 ] Guillaume Nodet commented on SM-529: Seems to run fine also for me. Do you have the associated log file ? Servicemix-Component's MPSSettingTest.java hangs indefinitely. -- Key: SM-529 URL: https://issues.apache.org/activemq/browse/SM-529 Project: ServiceMix Issue Type: Bug Reporter: Fritz Oconer Assigned To: Fritz Oconer Fix For: 3.1 Unit test org.apache.servicemix.components.mps.MPSSettingTest found in servicemix-components module hangs indefinitely. -- 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: GERONIMO-2324
On Aug 17, 2006, at 11:46 AM, System Architect wrote:I feel strongly that is should be stated: Testing is not a "relatively specific use case" but a natural stage in a lifecycle of an application. You cannot grow into an adult without being a kid first. And how well one were treated as a child, how much warmth one received from parents - defines the adulthood success or failure. This - unmodified - applies to any complex program. "Testing and dubugging" mode is a first class citizen of an application server and should be treated as such.But Ian made a good point - we don't always want test facilities being available in production environment. And because they are IDE specific - maybe they belong to the IDE adapter? Sort of modified SharedLib GBean installed by IDE integration. Yes this is certainly a good point. A modified SharedLib GBean is a good idea, but keep in mind that you would not want to change your application's deployment plan to reference this modified sharedlib and keep the existing dependency as-is. If this is possible, then its certainly something to look into. And then - the resolver, when looking for resources, asks this bean first before going to startdard Geronimo classloaders? This bean - in turn - maintains a pool of classloaders to dynamically supply IDE resources to other - IDE based - applications? Modifying the classloaders is something kind of what we tried last release, but it only solved very minimal set of cases and thus quickly discovered its not a runtime issue, its a build time issue. The builders themselves need to be changed, when the configuration is built up.~olegOn 8/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:Hi Sachin,I apologize in advance if I say anything exceedingly ignorant and/or foolish...Given that this functionality is meant for a relatively specific use case(utilizing Geronimo as a developer's test environment), and that havingthis functionality in a production environment is generally considered undesirable, would it be possible to implement this functionality within anexternal plugin which wouldn't normally be present in a Production or QAenvironment, but which could be installed in a development environment? IanIt's better to be hated for who you arethan loved for who you're notIan D. StewartDistributed Computing Engineer IIDSS eCommerce EngineeringJPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Sachin Patel [EMAIL PROTECTED] omTo Sent by: Sachin dev@geronimo.apache.org Patel cc [EMAIL PROTECTED] mSubject GERONIMO-2324 08/17/2006 08:06 AM Please respond to [EMAIL PROTECTED] he.orgSo does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don'tfully address the problem.(1) Need to be able to provide external individual jar entries to theshared library(2) Need to be able to add additional external classes folder to the shared library(3) Do both without having to modify the server config which requires aserver restart, which needs to be avoided. At worst case the shared libconfig should need to be recycled.This again I must stress, is a development time scenario to be able to treat Geronimo as a "test environment". I understand the implications ofdoing this, and agree that this should not be an in-production feature thatwe should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may notnecessarily make sense from a pure runtime perspective but certainly doesfrom a development standpoint.Input appreciated.-sachin -This transmission may contain information that is privileged,confidential, legally privileged, and/or exempt from disclosureunder applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, oruse of the information contained herein (including any reliancethereon) is STRICTLY PROHIBITED. Although this transmission andany attachments are believed to be free of any virus or other defect that might affect any computer system into which it isreceived and opened, it is the responsibility of the recipient toensure that it is virus free and no responsibility is accepted byJPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use.If you received this transmission in error, please immediatelycontact the sender and destroy the material in its entirety,whether in electronic or hard copy format. Thank you. -sachin
Re: GERONIMO-2324
On 8/17/06, Sachin Patel [EMAIL PROTECTED] wrote: On Aug 17, 2006, at 11:46 AM, System Architect wrote:I feel strongly that is should be stated: Testing is not a relatively specific use case but a natural stage in a lifecycle of an application. You cannot grow into an adult without being a kid first. And how well one were treated as a child, how much warmth one received from parents - defines the adulthood success or failure. This - unmodified - applies to any complex program. Testing and dubugging mode is a first class citizen of an application server and should be treated as such.But Ian made a good point - we don't always want test facilities being available in production environment. And because they are IDE specific - maybe they belong to the IDE adapter? Sort of modified SharedLib GBean installed by IDE integration. Yes this is certainly a good point. A modified SharedLib GBean is a good idea, but keep in mind that you would not want to change your application's deployment plan to reference this modified sharedlib and keep the existing dependency as-is. If this is possible, then itscertainlysomething to look into. Reference is just a name. What's deployed under that name - it could be the same SharedLib bean but with, possibly, another parameter, telling it to be more promiscuous. So IDE adapter can take control over it and manipulate it's bahavior? And then - the resolver, when looking for resources, asks this bean first before going to startdard Geronimo classloaders? This bean - in turn - maintains a pool of classloaders to dynamically supply IDE resources to other - IDE based - applications? Modifying the classloaders is something kind of what we tried last release, but it only solved very minimal set of cases and thus quickly discovered its not a runtime issue, its a build time issue. The builders themselves need to be changed, when the configuration is built up. And SharedLib is one of those builders? ~oleg On 8/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Sachin,I apologize in advance if I say anything exceedingly ignorant and/or foolish...Given that this functionality is meant for a relatively specific use case(utilizing Geronimo as a developer's test environment), and that having this functionality in a production environment is generally considered undesirable, would it be possible to implement this functionality within anexternal plugin which wouldn't normally be present in a Production or QA environment, but which could be installed in a development environment? IanIt's better to be hated for who you arethan loved for who you're notIan D. StewartDistributed Computing Engineer II DSS eCommerce EngineeringJPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Sachin Patel [EMAIL PROTECTED] omTo Sent by: Sachin dev@geronimo.apache.org Patelcc [EMAIL PROTECTED] mSubject GERONIMO-2324 08/17/2006 08:06 AM Please respond to [EMAIL PROTECTED] he.orgSo does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don'tfully address the problem. (1) Need to be able to provide external individual jar entries to theshared library(2) Need to be able to add additional external classes folder to the shared library(3) Do both without having to modify the server config which requires a server restart, which needs to be avoided. At worst case the shared libconfig should need to be recycled.This again I must stress, is a development time scenario to be able to treat Geronimo as a test environment. I understand the implications of doing this, and agree that this should not be an in-production feature thatwe should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may not necessarily make sense from a pure runtime perspective but certainly doesfrom a development standpoint.Input appreciated.-sachin -This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosureunder applicable law.If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, oruse of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED.Although this transmission andany attachments are believed to be free of any virus or other defect that might affect any computer system into which it isreceived and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted byJPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use.If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety,whether in electronic or hard copy format. Thank you. -sachin
[jira] Created: (SM-547) When the xbean deployer throws a RuntimeException or Error on first deployment, redeployment of the SU fails
When the xbean deployer throws a RuntimeException or Error on first deployment, redeployment of the SU fails Key: SM-547 URL: https://issues.apache.org/activemq/browse/SM-547 Project: ServiceMix Issue Type: Bug Components: servicemix-common Affects Versions: 3.0-M2 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M3 -- 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: (SM-547) When the xbean deployer throws a RuntimeException or Error on first deployment, redeployment of the SU fails
[ https://issues.apache.org/activemq/browse/SM-547?page=all ] Guillaume Nodet resolved SM-547. Resolution: Fixed Author: gnodet Date: Thu Aug 17 10:14:03 2006 New Revision: 432299 URL: http://svn.apache.org/viewvc?rev=432299view=rev Log: SM-547: When the xbean deployer throws a RuntimeException or Error on first deployment, redeployment of the SU fail Modified: incubator/servicemix/trunk/servicemix-common/src/main/java/org/apache/servicemix/common/AbstractDeployer.java incubator/servicemix/trunk/servicemix-common/src/main/java/org/apache/servicemix/common/ManagementSupport.java incubator/servicemix/trunk/servicemix-common/src/main/java/org/apache/servicemix/common/xbean/AbstractXBeanDeployer.java When the xbean deployer throws a RuntimeException or Error on first deployment, redeployment of the SU fails Key: SM-547 URL: https://issues.apache.org/activemq/browse/SM-547 Project: ServiceMix Issue Type: Bug Components: servicemix-common Affects Versions: 3.0-M2 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.0-M3 -- 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: GERONIMO-2324
On Aug 17, 2006, at 1:04 PM, System Architect wrote:On 8/17/06, Sachin Patel [EMAIL PROTECTED] wrote: On Aug 17, 2006, at 11:46 AM, System Architect wrote:I feel strongly that is should be stated: Testing is not a "relatively specific use case" but a natural stage in a lifecycle of an application. You cannot grow into an adult without being a kid first. And how well one were treated as a child, how much warmth one received from parents - defines the adulthood success or failure. This - unmodified - applies to any complex program. "Testing and dubugging" mode is a first class citizen of an application server and should be treated as such.But Ian made a good point - we don't always want test facilities being available in production environment. And because they are IDE specific - maybe they belong to the IDE adapter? Sort of modified SharedLib GBean installed by IDE integration. Yes this is certainly a good point. A modified SharedLib GBean is a good idea, but keep in mind that you would not want to change your application's deployment plan to reference this modified sharedlib and keep the existing dependency as-is. If this is possible, then its certainly something to look into. Reference is just a name. What's deployed under that name - it could be the same SharedLib bean but with, possibly, another parameter, telling it to be more promiscuous. So IDE adapter can take control over it and manipulate it's bahavior? And then - the resolver, when looking for resources, asks this bean first before going to startdard Geronimo classloaders? This bean - in turn - maintains a pool of classloaders to dynamically supply IDE resources to other - IDE based - applications? Modifying the classloaders is something kind of what we tried last release, but it only solved very minimal set of cases and thus quickly discovered its not a runtime issue, its a build time issue. The builders themselves need to be changed, when the configuration is built up. And SharedLib is one of those builders? No shared lib is not a builder just a simple Gbean. Some examples of the builders we have are EARConfigBuilder, TomcatBuilder, JettyBuilder connectorbuilder, , etc.. IIUC the deployment process is namespace driven and based on the content of your plan the appropriate builders get visited to build up the configuration. These individual builders locate process the contents of the application they are interested in. ~oleg On 8/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Sachin,I apologize in advance if I say anything exceedingly ignorant and/or foolish...Given that this functionality is meant for a relatively specific use case(utilizing Geronimo as a developer's test environment), and that having this functionality in a production environment is generally considered undesirable, would it be possible to implement this functionality within anexternal plugin which wouldn't normally be present in a Production or QA environment, but which could be installed in a development environment? IanIt's better to be hated for who you arethan loved for who you're notIan D. StewartDistributed Computing Engineer II DSS eCommerce EngineeringJPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Sachin Patel [EMAIL PROTECTED] omTo Sent by: Sachin dev@geronimo.apache.org Patel cc [EMAIL PROTECTED] mSubject GERONIMO-2324 08/17/2006 08:06 AM Please respond to [EMAIL PROTECTED] he.orgSo does anyone have any ideas on an agreeable solution to this JIRA? I don't think David's comments in the JIRA as an alternate solution don'tfully address the problem. (1) Need to be able to provide external individual jar entries to theshared library(2) Need to be able to add additional external classes folder to the shared library(3) Do both without having to modify the server config which requires a server restart, which needs to be avoided. At worst case the shared libconfig should need to be recycled.This again I must stress, is a development time scenario to be able to treat Geronimo as a "test environment". I understand the implications of doing this, and agree that this should not be an in-production feature thatwe should be promoting. But in order to improve our tooling integration with the runtime, we must start putting in features that may not necessarily make sense from a pure runtime perspective but certainly doesfrom a development standpoint.Input appreciated.-sachin -This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosureunder applicable law. If you are not the intended
Re: Global JNDI
Dain Sundstrom wrote: Earlier this week, David convinced me to help him get the JPA entity manager factories mapped into JNDI. And, that was the easy part, he also wanted it to work in G 1.1. Today, I finally got it working and wrote up some very rudimentary instruction on how to manually install it (need to figure out how to automate this) here: http://cwiki.apache.org/confluence/display/GMOxSBOX/Global+JNDI+Plugin Anyway, while writing this code I ended up writing a thread safe context which althought it isn't publicly modifiable can internally modify itself. I also wrote a subclass of this that watches the kernel for Contexts and adds them to the global name space. It occurred to me that with this code plus the code Krishnakumar Manu wrote in GERONIMO-2153 we may be able to have a complete global jndi plugin that can run in G 1.1. I'm going to try this over the next few days and let you'll if it works out. Looks interesting. Why would we put this in a patch branch and not just trunk for v1.2? Regards, Alan
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
Matt Hogstrom wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC Way to go Guillaume! Regards, Alan
Re: [ANNOUNCE] Welcome Grant McDonald as our newest committer
Guillaume Nodet wrote: We're pleased to announce that Grant McDonald has accepted the invitation to join Apache ServiceMix as a committer. Welcome Grant, and congratulations ! Congratulations Grant! Regards, Alan
Re: Organization and versioning of specs; a new proposal
David Blevins wrote: On Aug 16, 2006, at 5:16 PM, Jason Dillon wrote: On Aug 16, 2006, at 4:38 PM, David Blevins wrote: On Aug 16, 2006, at 3:28 PM, Jason Dillon wrote: On Aug 16, 2006, at 3:21 PM, David Blevins wrote: I guess I'd still prefer we do artifactId-version for the tag names as maven does. I'm planning on putting artifactId-version under artifactId/ but m2 handles this, all it needs it the root to exist. I see. When I suggested specs/tags/artifactId-version I hadn't noticed you expand that to specs/tags/artifactId/artifactId-version Seems like over-organizing as 70% of those directories will have only 1 file in them ever. The ones that do change, change only once or twice a year [1]. Maybe... I don't care either way. Ok, let's go with specs/tags/artifactId-version This is my preference as well. Regards, Alan
[jira] Closed: (GERONIMO-1739) Plugin migration to Maven 2: geronimo-izpack-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1739?page=all ] Jason Dillon closed GERONIMO-1739. -- Resolution: Won't Fix Strategy for installer needs to be reevaluated before any more work is done on integration with m2. Plugin migration to Maven 2: geronimo-izpack-plugin --- Key: GERONIMO-1739 URL: http://issues.apache.org/jira/browse/GERONIMO-1739 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.x Reporter: Jacek Laskowski Assigned To: Jason Dillon It's a task to keep track of the progress of the plugin build migration to Maven2 -- 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: Move trunk, tags and branches to server/*
+1 Regards, Alan David Blevins wrote: +1, it's gotten a bit awkward the way we have it now. -David On Aug 15, 2006, at 3:03 PM, Jason Dillon wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https://svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https://svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https://svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason
Re: Console JACC Security Error in 1.1.1
FYI. Fixed. Regards, Alan Alan D. Cabrera wrote: I found the problem and will fix it tonight. Regards, Alan Aaron Mulder wrote: I'm not sure if this is related to the recent web app security fix or not. I hacked the build enough that I got the 1.1.1 server running. I went to the console, went to the database pool screen, selected that I wanted to create a new pool, filled out the name and DB type on that screen and hit submit, and got the error below. I have no idea why it only came up on that submission and not any of the previous ones (though it was the first POST request I think). Thanks, Aaron 18:19:51,940 WARN [/console] /console/portal/services/services_jdbc/_rp_services_jdbc_row1_col1_p1_adapterDisplayName/1_TranQL0x8Generic0x8JDBC0x8Resource0x8Adapter/_rp_services_jdbc_row1_col1_p1_rarPath/1_tranql0x3tranql-connector0x310x220x3rar/_rp_services_jdbc_row1_col1_p1_mode/1_params/_rp_services_jdbc_row1_col1_p1_driverClass/1_com0x2mysql0x2jdbc0x2Driver/_pm_services_jdbc_row1_col1_p1/view/_rp_services_jdbc_row1_col1_p1_dbtype/1_MySQL/_rp_services_jdbc_row1_col1_p1_urlPrototype/1_jdbc%3Amysql%3A0x30x3%7BHost%7D%3A%7BPort%7D0x3%7BDatabase%7D/_st_services_jdbc_row1_col1_p1/normal/_ps_services_jdbc_row1_col1_p1/normal/_pid/services_jdbc_row1_col1_p1/_md_services_jdbc_row1_col1_p1/view/_rp_services_jdbc_row1_col1_p1_name/1_JPAPool: java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.init(WebUserDataPermission.java:83) at org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.checkSecurityConstraints(SecurityContextBeforeAfter.java:194) at org.apache.geronimo.jetty.JettyWebAppContext.checkSecurityConstraints(JettyWebAppContext.java:607) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:432) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWebApplicationHandler.java:58) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
[jira] Commented: (GERONIMO-2174) Remove modules/console-web
[
http://issues.apache.org/jira/browse/GERONIMO-2174?page=comments#action_12428737
]
Jason Dillon commented on GERONIMO-2174:
This is a pending merge from dead-1.2...
{quote}
r383111 | jlaskowski | 2006-03-04 05:26:30 -0800 (Sat, 04 Mar 2006) | 4 lines
Changed paths:
D /geronimo/trunk/modules/console-web
GERONIMO-1667 Remove console-web module as it has now become obsolete
There's a brand new console in applications/console*
{quote}
Remove modules/console-web
Key: GERONIMO-2174
URL: http://issues.apache.org/jira/browse/GERONIMO-2174
Project: Geronimo
Issue Type: Task
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Priority: Trivial
According to Aaron, this is old:
{quote}
It's old code and should be removed.
Thanks,
Aaron
{quote}
Remove as part of m1 cleanup when m2 is the default.
--
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 build - validating
--- Jason Dillon [EMAIL PROTECTED] wrote: IMO we should not overload the scope mechanism here, but define new configuration elements that allow us to add the additional metadata needed Bill, if you do not want to improve the existing car-maven-plugin, you will need to use the scope. just like how I added classpathPrefix to be used to control the prefix for manifest entries. IMO, the classpath should be constructed dynamically using the transitive dependencies of the modules, i.e for j2ee-system config use dependencies of the system module. The way it is now is very hard to maintain. Every time a dependency is changed in the system module, most executable configurations must be updated manually. The current way of maintaining hard coded dependencies in the classPath element are only marginally better than maintaining a large string of the original implementaion. Adding prefix to these dependencies is trivial. Thanks Anita Then the m2 dependencies would only really be used to control build order for cars. --jason On Aug 17, 2006, at 8:59 AM, anita kulshreshtha wrote: Oops.., the correct link is : http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/% [EMAIL PROTECTED] Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: inline... --- David Jencks [EMAIL PROTECTED] wrote: On Aug 16, 2006, at 4:33 PM, Bill Dudney wrote: Hi All, i've been using the m2 build for several days now and I've noticed that while it works well there are several details that are still not nailed down. Particularly I've been hitting lots of dependency issues around deployment. So what I've started doing is slogging through each of them one at a time, posting a jira and a patch. It struck me that there are probably similar issues throughout the server WRT the m2 build. I'm open to other methods (and would love to hear of a silver bullet:) but seems to me that we need to basically hit everything in the console and tools and such and make sure it works so we can be sure the dependencies are correct. While I don't think I'll be able to hit 'everything' I'll try to poke on most of the console and the CLI tools and make sure that it 'works'. My plan of attack: 1 - provide patches for the stuff i know about now (tranql/tranql- connector is missing for example from the repository) 2 - finish getting deployment working from the console (data sources, ejb-jar's, wars etc) 3 - poke on the rest of the console 4 - deploy daytrader 5 - anything else anyone comes up with I will be posting bunches of jira's and fixes over the next few days as I work through this stuff (unless someone has a better idea about how to tackle it). This is great that you are taking a look at this. Here are some tips that may help fix dependency problems: 1. The modules use resources2/META-INF/geronimo-dependency.xml files to specify transitive dependencies. We could use a lot more of these. You may find the best solution to a classpath problem is adding one of these. 2. There are often several ways to get a jar into a classloader, such as a) depending on a car, from a car b) depending on a jar from a jar (using geornimo-dependency.xml) c) depending directly on the jar from a car I'd say this is the order of preference 3) It is really important that the builder cars don't start any runtime cars: if you violate this rule the packaging plugin is likely to stop working. You can have 2.a and enforce this rule by using the scope element in the dependency and setting it to scopeclasses/ scope. This means the dependency's classloader will be constructed and available for use but that no services from the car will be started. This might be helpful in adding dependency using 2.a - http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/ browser Thanks Anita This is in my experience somewhat nerve wracking and gruesome work, so I really appreciate your taking it on, and I'll do whatever I can to help you with it. thanks david jencks TTFN, -bd- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Trimmed more Unnecessary changes out of all_changes.log
I've pruned most of the build system changes, and the javamail- transport bits. Down to 113 revisions marked as Not Merged. --jason
[jira] Commented: (GERONIMO-1557) When you enter the url of a web service in the console You should get a page showing the service name
[ http://issues.apache.org/jira/browse/GERONIMO-1557?page=comments#action_12428740 ] Donald Woods commented on GERONIMO-1557: This has applied to 1.1.1 - Revision: 423005 Author: djencks Date: 4:08:10 AM, Tuesday, July 18, 2006 Message: GERONIMO-1557 show the axis page for a url of a web service Modified : /geronimo/branches/1.1/modules/axis/src/java/org/apache/geronimo/axis/server/AxisWebServiceContainer.java Has it been applied to Trunk? When you enter the url of a web service in the console You should get a page showing the service name - Key: GERONIMO-1557 URL: http://issues.apache.org/jira/browse/GERONIMO-1557 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: webservices Affects Versions: 1.0 Environment: All Reporter: Manu T George Assigned To: David Jencks Priority: Minor Fix For: 1.1.1 Attachments: AxisServiceBuilder.patch, AxisServiceBuilder.patch, AxisWebServiceContainer.patch, AxisWebServiceContainer.patch, AxisWebServiceContainer.patch When you type the URL of a web service in a browser without the ?wsdl parameter what happens is that a SOAPFault is thrown. Instead we should show a HTML page with the message This is a web service followed by the service name. -- 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-1986) TranQL Connector doesn't check Driver Class during deployment
[ http://issues.apache.org/jira/browse/GERONIMO-1986?page=all ] Donald Woods updated GERONIMO-1986: --- Fix Version/s: 1.1.2 (was: 1.1.x) Affects Version/s: 1.1 1.1.2 TranQL Connector doesn't check Driver Class during deployment - Key: GERONIMO-1986 URL: http://issues.apache.org/jira/browse/GERONIMO-1986 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector, deployment Affects Versions: 1.1, 1.1.1, 1.1.2 Reporter: Aaron Mulder Assigned To: Matt Hogstrom Fix For: 1.2, 1.1.2 Attachments: db-plan-no-deps.xml, tranql-1986-updated.patch, tranql-1986.patch If you deploy the attached plan with the TranQL connector RAR, the distribute phase is successful, but it fails during start because the driver class is not available. It would be much better to find a way to validate the driver class during distribution. I'm not sure how complex this will be; it may involve instanting things during distribution that normally aren't instantiated until start time. But the current behavior is definitely not desirable. -- 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-2113) Geronimo doesn't start if restarted using another JDK
[ http://issues.apache.org/jira/browse/GERONIMO-2113?page=all ] Donald Woods updated GERONIMO-2113: --- Fix Version/s: 1.1.2 1.2 (was: 1.1.x) Affects Version/s: 1.1.1 1.2 Geronimo doesn't start if restarted using another JDK - Key: GERONIMO-2113 URL: http://issues.apache.org/jira/browse/GERONIMO-2113 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: transaction manager Affects Versions: 1.2, 1.1, 1.1.1 Reporter: Nellya Udovichenko Assigned To: David Jencks Fix For: 1.2, 1.1.2 Attachments: HOWLLog.patch, HOWLLog.patch There is a bug in HOWL. At Geronimo launching time the file content control sum is calculated by the function java.nio.ByteBuffer.hashCode(). Therefore, if hash code algorithms of various JDKs differ Geronimo doesn't start. The bug is repaired in howl-1.0.1 by the introducing of the new parameter adler32Checksum. If the parameter value is false the control sum is calculated by the function java.nio.ByteBuffer.hashCode() otherwise it is calculated using ADLER-32 algorithm. Attached patch adds the parameter to configs/j2ee-server/src/plan/plan.xml and to org.apache.geronimo.transaction.log.HOWLLog gbean with default value 'true'. -- 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
Fwd: Trimmed more Unnecessary changes out of all_changes.log
FYI, I added pending-merge-log.sh which will svn log the remaining changes to easily see what needs to be done.--jasonBegin forwarded message:From: Jason Dillon [EMAIL PROTECTED]Date: August 17, 2006 11:52:27 AM PDTTo: dev@geronimo.apache.orgSubject: Trimmed more Unnecessary changes out of all_changes.log I've pruned most of the build system changes, and the javamail-transport bits.Down to 113 revisions marked as Not Merged.--jason
[jira] Closed: (GERONIMO-2174) Remove modules/console-web
[ http://issues.apache.org/jira/browse/GERONIMO-2174?page=all ]
Jason Dillon closed GERONIMO-2174.
--
Fix Version/s: 1.2
Resolution: Fixed
Remove modules/console-web
Key: GERONIMO-2174
URL: http://issues.apache.org/jira/browse/GERONIMO-2174
Project: Geronimo
Issue Type: Task
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Priority: Trivial
Fix For: 1.2
According to Aaron, this is old:
{quote}
It's old code and should be removed.
Thanks,
Aaron
{quote}
Remove as part of m1 cleanup when m2 is the default.
--
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: (GERONIMO-1672) Module migration to Maven2: security
[ http://issues.apache.org/jira/browse/GERONIMO-1672?page=all ] Jason Dillon closed GERONIMO-1672. -- Fix Version/s: 1.2 (was: 1.x) Resolution: Fixed This module is converted to m2. Module migration to Maven2: security - Key: GERONIMO-1672 URL: http://issues.apache.org/jira/browse/GERONIMO-1672 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: security Affects Versions: 1.x Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 1.2 Attachments: m2-log4j.patch, pom.patch, pom.patch, pom.patch -- 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: (GERONIMO-1644) Migrate kernel module to Maven2
[ http://issues.apache.org/jira/browse/GERONIMO-1644?page=all ] Jason Dillon closed GERONIMO-1644. -- Fix Version/s: 1.2 Resolution: Fixed Assignee: Jason Dillon (was: Jacek Laskowski) This module is converted to m2. Migrate kernel module to Maven2 --- Key: GERONIMO-1644 URL: http://issues.apache.org/jira/browse/GERONIMO-1644 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: kernel Affects Versions: 1.x Reporter: Jacek Laskowski Assigned To: Jason Dillon Fix For: 1.2 It's a task to help keep track of the progress of the kernel module build migration to Maven2 -- 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-1813) When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory
[ http://issues.apache.org/jira/browse/GERONIMO-1813?page=all ] Donald Woods updated GERONIMO-1813: --- Attachment: hotdeploy_projectxml_06042006.txt Also need to apply hotdeploy_projectxml_06042006.txt (which was created against the latest 1.1.1 branch), which includes geronimo-deployment jar for the new dependency on org.apache.geronimo.deployment.util.DeploymentUtil. When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory -- Key: GERONIMO-1813 URL: http://issues.apache.org/jira/browse/GERONIMO-1813 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Hot Deploy Dir Affects Versions: 1.1 Environment: Win2k , JDK 1.4.2 Reporter: Mansoor Priority: Minor Fix For: 1.1.x, 1.2 Attachments: hotdeploy_patch1_06042006.txt, hotdeploy_projectxml_06042006.txt Hi , Problem : When already an application module say (hello.war) is deployed (either by using manually or hot deploy procedure ) , And when some one try to hot deploy the same application with same or different name ( say hello.war | hello2.war | hello2 directory ) , the server throws an exception saying there exists already an application deployed , But doesn't delete the module ( hello.war | hello2.war | hello2 directory) from hot deploy directory . Thus the next time the server starts , it tries to deploy the same module once again. Here i have a piece of code put into DirectoryHotDeployer.java file , which can solve the above issue and also to some extend users can get clean picture. Basically it deletes the asset from deploy directory ,which got failed to hot deploy -- 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-2113) Geronimo doesn't start if restarted using another JDK
[
http://issues.apache.org/jira/browse/GERONIMO-2113?page=comments#action_12428764
]
Jason Dillon commented on GERONIMO-2113:
What is up with this issue? Seems like lowhanging fruit...
Patch is complaining though:
{noformat}
***
*** 404,409
infoFactory.addAttribute(bufferClassName, String.class, true);
infoFactory.addAttribute(bufferSizeKBytes, Integer.TYPE, true);
infoFactory.addAttribute(checksumEnabled, Boolean.TYPE, true);
infoFactory.addAttribute(flushSleepTimeMilliseconds, Integer.TYPE,
true);
infoFactory.addAttribute(logFileDir, String.class, true);
infoFactory.addAttribute(logFileExt, String.class, true);
--- 414,420
infoFactory.addAttribute(bufferClassName, String.class, true);
infoFactory.addAttribute(bufferSizeKBytes, Integer.TYPE, true);
infoFactory.addAttribute(checksumEnabled, Boolean.TYPE, true);
+ infoFactory.addAttribute(adler32Checksum, Boolean.TYPE, true);
infoFactory.addAttribute(flushSleepTimeMilliseconds, Integer.TYPE,
true);
infoFactory.addAttribute(logFileDir, String.class, true);
infoFactory.addAttribute(logFileExt, String.class, true);
***
*** 423,428
bufferClassName,
bufferSizeKBytes,
checksumEnabled,
flushSleepTimeMilliseconds,
logFileDir,
logFileExt,
--- 434,440
bufferClassName,
bufferSizeKBytes,
checksumEnabled,
+ adler32ChecksumEnabled,
flushSleepTimeMilliseconds,
logFileDir,
logFileExt,
{noformat}
Geronimo doesn't start if restarted using another JDK
-
Key: GERONIMO-2113
URL: http://issues.apache.org/jira/browse/GERONIMO-2113
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: transaction manager
Affects Versions: 1.2, 1.1, 1.1.1
Reporter: Nellya Udovichenko
Assigned To: David Jencks
Fix For: 1.2, 1.1.2
Attachments: HOWLLog.patch, HOWLLog.patch
There is a bug in HOWL. At Geronimo launching time the file content control
sum is calculated by the function
java.nio.ByteBuffer.hashCode(). Therefore, if hash code algorithms of various
JDKs differ Geronimo doesn't
start.
The bug is repaired in howl-1.0.1 by the introducing of the new parameter
adler32Checksum. If the parameter
value is false the control sum is calculated by the function
java.nio.ByteBuffer.hashCode() otherwise it is calculated using
ADLER-32 algorithm.
Attached patch adds the parameter to configs/j2ee-server/src/plan/plan.xml
and
to org.apache.geronimo.transaction.log.HOWLLog gbean with default value
'true'.
--
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
CreateSession fails and remains in wait mode in C#
Hello,
I am trying to use the .Net Message Service
API(https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-dotnet/)
in C# to communicate to ACtive MQ. Using the following code i am able to
successfully connect to Activer MQ but when i am trying to create a session
using connection.CreatSession() method it goes in wait mode and nothing
happens after that
IConnectionFactory factory = new ConnectionFactory(new
Uri(tcp://BldFriday:61613));
using (IConnection connection = factory.CreateConnection())
{
connection.Start();
Console.WriteLine(Created a connection! + connection );
ISession session = connection.CreateSession();
IDestination destination = session.GetQueue(FOO.BAR);
Console.WriteLine(Using destination: + destination);
.
In the Class FutureResponse there is a while loop in the Response property
as the reponse object is null it loops in here and never exits the loop.
I am facing the same problem in Windows and Linux.
If you come across this issue please help me to solve.
thanks
Sudhakar R
--
View this message in context:
http://www.nabble.com/CreateSession-fails-and-remains-in-wait-mode-in-C--tf2123542.html#a5858227
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Global JNDI
On Aug 17, 2006, at 10:57 AM, Alan D. Cabrera wrote: Dain Sundstrom wrote: Earlier this week, David convinced me to help him get the JPA entity manager factories mapped into JNDI. And, that was the easy part, he also wanted it to work in G 1.1. Today, I finally got it working and wrote up some very rudimentary instruction on how to manually install it (need to figure out how to automate this) here: http://cwiki.apache.org/confluence/display/GMOxSBOX/Global+JNDI +Plugin Anyway, while writing this code I ended up writing a thread safe context which althought it isn't publicly modifiable can internally modify itself. I also wrote a subclass of this that watches the kernel for Contexts and adds them to the global name space. It occurred to me that with this code plus the code Krishnakumar Manu wrote in GERONIMO-2153 we may be able to have a complete global jndi plugin that can run in G 1.1. I'm going to try this over the next few days and let you'll if it works out. Looks interesting. Why would we put this in a patch branch and not just trunk for v1.2? I'm actually working on a new plugin that will run in 1.1+ in the sandbox (not a branch). After I get it working, I think we should look at pulling it directly into 1.2. -dain
[jira] Resolved: (AMQ-883) NMS asynchronous consumption of queued messages
[ https://issues.apache.org/activemq/browse/AMQ-883?page=all ] james strachan resolved AMQ-883. Fix Version/s: 4.1 Resolution: Fixed Thanks for the suggestions and ideas on how to fix it! :) I've added a bunch more test cases to AsyncConsumeTest to test out creating the consumer before the send, after it or before the send with adding the listener after it and they all are now working fine. NMS asynchronous consumption of queued messages --- Key: AMQ-883 URL: https://issues.apache.org/activemq/browse/AMQ-883 Project: ActiveMQ Issue Type: Bug Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Win XP, AMQ 4.0.2 standalone broker, Java message sender (JMS), C# (NMS) receiver Reporter: Bryan Schmidt Fix For: 4.1 1. Several messages are sent to a queue 2. NMS client subscribes 3. Queued messages are not received by NMS client 4. Another message is sent to the queue (while the NMS client is subscribed) 5. NMS client receives all messages Same setup using Java publisher and subscriber behaves properly (queued messages are sent to the subscriber immediately). Editting the AsyncConsumeTest unit test can reproduce the problem and cause the test to fail: In the textMessageSRExample test, move the consumer logic below the producer logic. (I.e. have the message sent to a queue before the consumer subscribes). -- 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-865) C# Client's Listener doesn't receive messages if you don't explicitly call Subscribe
[ https://issues.apache.org/activemq/browse/AMQ-865?page=all ]
james strachan resolved AMQ-865.
Fix Version/s: 4.1
Resolution: Fixed
Patch applied in SVN trunk if you want to try along with the test cases for
this issue and the related AMQ-883
C# Client's Listener doesn't receive messages if you don't explicitly call
Subscribe
Key: AMQ-865
URL: https://issues.apache.org/activemq/browse/AMQ-865
Project: ActiveMQ
Issue Type: Bug
Components: NMS (C# client)
Environment: Windows XP, VS 2005, ActiveMQ 4.0.1
Reporter: Denis Abramov
Fix For: 4.1
Easiest way to reproduce the bug would be to start the consumer using the
following code and then AFTER the consumer starts, start some producer
(either java or C#) and you will notice that the consumer will not get any
messages (through trial and error I found that calling Receive() on the
consumer at least once will make you lose a message but the listener will
kick back in):
using System;
using ActiveMQ;
using ActiveMQ.Commands;
using NMS;
namespace JMSClient
{
/// summary
/// Summary description for Class1.
/// /summary
class Class1
{
/// summary
/// The main entry point for the application.
/// /summary
[STAThread]
static void Main(string[] args)
{
IConnectionFactory factory = new ConnectionFactory(new
Uri(tcp://localhost:61616?jms.useAsyncSend=true));
using (IConnection connection = factory.CreateConnection())
{
Console.WriteLine(Created a connection!);
ISession session = connection.CreateSession();
IDestination destination =
session.GetQueue(EXCEL.TESTQUEUE);
Console.WriteLine(Using destination: + destination);
// lets create a consumer and producer
IMessageConsumer consumer =
session.CreateConsumer(destination);
consumer.Listener += new MessageListener(consumer_Listener);
while (true);
}
}
static void consumer_Listener(IMessage message)
{
if (message == null)
{
Console.WriteLine(No message received!);
}
else
{
Console.WriteLine(Received message with text: +
((ActiveMQTextMessage)message).Text);
}
}
}
}
--
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: CreateSession fails and remains in wait mode in C#
Ah - you are connecting on the default stomp port (61613) could you
try connecting on 61616?
On 8/17/06, Sudhakar [EMAIL PROTECTED] wrote:
Hello,
I am trying to use the .Net Message Service
API(https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-dotnet/)
in C# to communicate to ACtive MQ. Using the following code i am able to
successfully connect to Activer MQ but when i am trying to create a session
using connection.CreatSession() method it goes in wait mode and nothing
happens after that
IConnectionFactory factory = new ConnectionFactory(new
Uri(tcp://BldFriday:61613));
using (IConnection connection = factory.CreateConnection())
{
connection.Start();
Console.WriteLine(Created a connection! + connection );
ISession session = connection.CreateSession();
IDestination destination = session.GetQueue(FOO.BAR);
Console.WriteLine(Using destination: + destination);
.
In the Class FutureResponse there is a while loop in the Response property
as the reponse object is null it loops in here and never exits the loop.
I am facing the same problem in Windows and Linux.
If you come across this issue please help me to solve.
thanks
Sudhakar R
--
View this message in context:
http://www.nabble.com/CreateSession-fails-and-remains-in-wait-mode-in-C--tf2123542.html#a5858227
Sent from the ActiveMQ - Dev forum at Nabble.com.
--
James
---
http://radio.weblogs.com/0112098/
Re: CreateSession fails and remains in wait mode in C#
Thanks a lot. It worked. Sorry it was my mistake.
James.Strachan wrote:
Ah - you are connecting on the default stomp port (61613) could you
try connecting on 61616?
On 8/17/06, Sudhakar [EMAIL PROTECTED] wrote:
Hello,
I am trying to use the .Net Message Service
API(https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-dotnet/)
in C# to communicate to ACtive MQ. Using the following code i am able to
successfully connect to Activer MQ but when i am trying to create a
session
using connection.CreatSession() method it goes in wait mode and nothing
happens after that
IConnectionFactory factory = new ConnectionFactory(new
Uri(tcp://BldFriday:61613));
using (IConnection connection = factory.CreateConnection())
{
connection.Start();
Console.WriteLine(Created a connection! + connection );
ISession session = connection.CreateSession();
IDestination destination = session.GetQueue(FOO.BAR);
Console.WriteLine(Using destination: + destination);
.
In the Class FutureResponse there is a while loop in the Response
property
as the reponse object is null it loops in here and never exits the loop.
I am facing the same problem in Windows and Linux.
If you come across this issue please help me to solve.
thanks
Sudhakar R
--
View this message in context:
http://www.nabble.com/CreateSession-fails-and-remains-in-wait-mode-in-C--tf2123542.html#a5858227
Sent from the ActiveMQ - Dev forum at Nabble.com.
--
James
---
http://radio.weblogs.com/0112098/
--
View this message in context:
http://www.nabble.com/CreateSession-fails-and-remains-in-wait-mode-in-C--tf2123542.html#a5859322
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: m2 build - validating
On Aug 17, 2006, at 11:51 AM, anita kulshreshtha wrote: Bill, if you do not want to improve the existing car-maven-plugin, you will need to use the scope. Who said anything about not wanting to improve it? just like how I added classpathPrefix to be used to control the prefix for manifest entries. IMO, the classpath should be constructed dynamically using the transitive dependencies of the modules, i.e for j2ee-system config use dependencies of the system module. The way it is now is very hard to maintain. Every time a dependency is changed in the system module, most executable configurations must be updated manually. The current way of maintaining hard coded dependencies in the classPath element are only marginally better than maintaining a large string of the original implementaion. Adding prefix to these dependencies is trivial. I agree it was a small step forward... but now we can pick up version information from maven and not from properties, which means less configuration. I am not sure how to get this information transitively yet, as soon as I discover the right magic I will implement it. I think we need to get the magic spell for transitivity before we could implement something similar to pick up deps added to plans or else it will get out of control. --jason
Re: m2 build - validating
And it seems I have the magic incantation now :-) Going to see how well I can cast it on the car plugin later today. --jason On Aug 17, 2006, at 11:51 AM, anita kulshreshtha wrote: --- Jason Dillon [EMAIL PROTECTED] wrote: IMO we should not overload the scope mechanism here, but define new configuration elements that allow us to add the additional metadata needed Bill, if you do not want to improve the existing car-maven-plugin, you will need to use the scope. just like how I added classpathPrefix to be used to control the prefix for manifest entries. IMO, the classpath should be constructed dynamically using the transitive dependencies of the modules, i.e for j2ee-system config use dependencies of the system module. The way it is now is very hard to maintain. Every time a dependency is changed in the system module, most executable configurations must be updated manually. The current way of maintaining hard coded dependencies in the classPath element are only marginally better than maintaining a large string of the original implementaion. Adding prefix to these dependencies is trivial. Thanks Anita Then the m2 dependencies would only really be used to control build order for cars. --jason On Aug 17, 2006, at 8:59 AM, anita kulshreshtha wrote: Oops.., the correct link is : http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/% [EMAIL PROTECTED] Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: inline... --- David Jencks [EMAIL PROTECTED] wrote: On Aug 16, 2006, at 4:33 PM, Bill Dudney wrote: Hi All, i've been using the m2 build for several days now and I've noticed that while it works well there are several details that are still not nailed down. Particularly I've been hitting lots of dependency issues around deployment. So what I've started doing is slogging through each of them one at a time, posting a jira and a patch. It struck me that there are probably similar issues throughout the server WRT the m2 build. I'm open to other methods (and would love to hear of a silver bullet:) but seems to me that we need to basically hit everything in the console and tools and such and make sure it works so we can be sure the dependencies are correct. While I don't think I'll be able to hit 'everything' I'll try to poke on most of the console and the CLI tools and make sure that it 'works'. My plan of attack: 1 - provide patches for the stuff i know about now (tranql/tranql- connector is missing for example from the repository) 2 - finish getting deployment working from the console (data sources, ejb-jar's, wars etc) 3 - poke on the rest of the console 4 - deploy daytrader 5 - anything else anyone comes up with I will be posting bunches of jira's and fixes over the next few days as I work through this stuff (unless someone has a better idea about how to tackle it). This is great that you are taking a look at this. Here are some tips that may help fix dependency problems: 1. The modules use resources2/META-INF/geronimo-dependency.xml files to specify transitive dependencies. We could use a lot more of these. You may find the best solution to a classpath problem is adding one of these. 2. There are often several ways to get a jar into a classloader, such as a) depending on a car, from a car b) depending on a jar from a jar (using geornimo-dependency.xml) c) depending directly on the jar from a car I'd say this is the order of preference 3) It is really important that the builder cars don't start any runtime cars: if you violate this rule the packaging plugin is likely to stop working. You can have 2.a and enforce this rule by using the scope element in the dependency and setting it to scopeclasses/ scope. This means the dependency's classloader will be constructed and available for use but that no services from the car will be started. This might be helpful in adding dependency using 2.a - http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/ browser Thanks Anita This is in my experience somewhat nerve wracking and gruesome work, so I really appreciate your taking it on, and I'll do whatever I can to help you with it. thanks david jencks TTFN, -bd- __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=comments#action_12428791 ] Geir Magnusson Jr commented on GERONIMO-2307: - following a voice discussion, I've asked formally for Sun to a) confirm no problem with typing the schemas in oursleves, and putting in SVN and distributions under the Apache license. b) grant persmission to take their schemas, strip any value add information that isn't required for functional or conformance reasons, (such as xsd:documentation), put under Apache license, and into SVN and distributions - just save us the typing. Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Geir Magnusson Jr Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. -- 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: New car-maven-plugin issue
I have seen this problem happen only when a m1 repo is in the mix... something about m2 getting confused about metadata.xml bits...Do you have an m1 repo in your build?--jasonOn Aug 15, 2006, at 4:13 PM, Guillaume Nodet wrote:Trying to build a plugin to integrate ServiceMix in G 1.1,i' ve just seen that the deployer is unable to handle snapshots in m2 repo, as they are deployed with a timestamped name and notwith the SNAPSHOT version. For example, http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/servicemix-core/3.0-incubating-SNAPSHOT/servicemix-core-3.0-incubating-20060815.104506-23.jar Not being able to use snapshots is not very friendly when you are developing ;)Is this an oversight or did I miss something ? On 8/13/06, Aaron Mulder [EMAIL PROTECTED] wrote: So I can build Plugin A (quartz-scheduler). But the build for PluginB (quartz-deployer) which depends on Plugin A fails to create the CARwith an error like this:INFO] [ERROR] FATAL ERROR[INFO] [INFO] org.gplugins.quartz.QuartzScheduler in classloadergplugins/quartz-deployer/0.3/car[INFO] [INFO] Tracejava.lang.NoClassDefFoundError: org.gplugins.quartz.QuartzScheduler inclassloader gplugins/quartz-deployer/0.3/car...at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java :76)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java :290)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration (ServiceConfigBuilder.java:211)So it's saying that a quartz-deployer GBean can't find aquartz-scheduler class. Now, both the POM for quartz-deployer and theplan for quartz-deployer include an entry for the quartz-scheduler CAR:POM:dependencygroupIdgplugins/groupIdartifactIdquartz-scheduler/artifactIdscopeprovided/scope typecar/type/dependencytarget/plan/plan.xml: dependencygroupIdgplugins/groupIdartifactIdquartz-scheduler/artifactId typecar/type /dependencyAnd when I deploy the quartz-deployer JAR by hand using the plan attarget/plan/plan.xml, then it works fine.What I don't understand is, how can service-config-builder not load the quartz-scheduler CAR dependency and then claim that the classesare missing? If it loaded the dependency, the classes should be there(e.g. it works if deployed to a real server). If it didn't load the dependency, why didn't it get a missing dependency error?Thanks, Aaron-- Cheers,Guillaume Nodet
Re: Organization and versioning of specs; a new proposal
On Aug 17, 2006, at 11:10 AM, Alan D. Cabrera wrote: David Blevins wrote: Ok, let's go with specs/tags/artifactId-version This is my preference as well. It is easy enough to change later if/when the top-level tags dir becomes unwieldy... so I am fine with this. --jason
[jira] Commented: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=comments#action_12428806 ] Geir Magnusson Jr commented on GERONIMO-2307: - Clearly the documents as is are not appropriate for redistribution, as they say no redistribution. Sun will not allow us to take their documents and snip out their value-add to save the typing. So we should just create these fresh from the spec. geir Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Geir Magnusson Jr Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. -- 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
Release schedule
I am wondering what would be the estimate date for 4.1 release? Do we have an idea of when and what releases are going to happen? How many more 4.0.x releases will we have? Thanks. -- View this message in context: http://www.nabble.com/Release-schedule-tf2124265.html#a5860619 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: [VOTE] Release Apache ActiveMQ 4.0.2 (RC 3)
Yep. I'll run the tally. On 8/17/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Maybe it's time to ask the incubator PMC to vote on this release ? 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 -- Cheers, Guillaume Nodet -- Regards, Hiram Blog: http://hiramchirino.com
[VOTE RESULT] Release Apache ActiveMQ 4.0.2 (RC 3)
Hi folks, Thanks for taking the time to check the release. Vote passes with 8 +1's . We just need to get the incubator PMC to now approve the release. +1 Votes: Hiram Chirino James Strachan Rob Davies Guillaume Nodet Kevan Miller Alan D. Cabrera Aaron Mulder Brian McCallister No +/- 0 or -1's -- Regards, Hiram Blog: http://hiramchirino.com
New module: geronimo-testsupport
I'd like to add a new module to our build, geronimo-testsupport,
which provides at the moment a single TestSupport class which sets up
logging and some other commonly used bits (like the File ref to $
{basedir}).
And then incrementally I'd like for all of our test classes to extend
from this instead of junit.framework.TestCase.
Any objections?
--jason
[jira] Created: (GERONIMO-2330) mismatched constructor gbean error message doesn't actually show the expected classes
mismatched constructor gbean error message doesn't actually show the expected classes - Key: GERONIMO-2330 URL: http://issues.apache.org/jira/browse/GERONIMO-2330 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: kernel Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Priority: Minor Fix For: 1.2 If the constructor declared in the gbean into doesn't match an actual constructor, GBeanInstance throws an exception that's supposed to explain the mismatch. However instead of showing the classes it shows [Ljava.lang.Class... array.toString() isn't very informative. -- 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: (GERONIMO-2330) mismatched constructor gbean error message doesn't actually show the expected classes
[ http://issues.apache.org/jira/browse/GERONIMO-2330?page=all ] David Jencks closed GERONIMO-2330. -- Resolution: Fixed fixed rev 432413 mismatched constructor gbean error message doesn't actually show the expected classes - Key: GERONIMO-2330 URL: http://issues.apache.org/jira/browse/GERONIMO-2330 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Priority: Minor Fix For: 1.2 If the constructor declared in the gbean into doesn't match an actual constructor, GBeanInstance throws an exception that's supposed to explain the mismatch. However instead of showing the classes it shows [Ljava.lang.Class... array.toString() isn't very informative. -- 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: New module: geronimo-testsupport
YAY!!!
Can you make the File ref to ${basedir} work in idea without setting
test properties?
thanks
david jencks
On Aug 17, 2006, at 3:24 PM, Jason Dillon wrote:
I'd like to add a new module to our build, geronimo-testsupport,
which provides at the moment a single TestSupport class which sets
up logging and some other commonly used bits (like the File ref to $
{basedir}).
And then incrementally I'd like for all of our test classes to
extend from this instead of junit.framework.TestCase.
Any objections?
--jason
Re: New module: geronimo-testsupport
Most likely.
--jason
On Aug 17, 2006, at 3:42 PM, David Jencks wrote:
YAY!!!
Can you make the File ref to ${basedir} work in idea without
setting test properties?
thanks
david jencks
On Aug 17, 2006, at 3:24 PM, Jason Dillon wrote:
I'd like to add a new module to our build, geronimo-testsupport,
which provides at the moment a single TestSupport class which sets
up logging and some other commonly used bits (like the File ref to
${basedir}).
And then incrementally I'd like for all of our test classes to
extend from this instead of junit.framework.TestCase.
Any objections?
--jason
Re: Organization and versioning of specs; a new proposal
I'm trying to motivate to writing this... :-\
--jason
On Aug 16, 2006, at 7:41 PM, David Blevins wrote:
On Aug 16, 2006, at 7:13 AM, Kevan Miller wrote:
On Aug 16, 2006, at 3:56 AM, Jason Dillon wrote:
What is the status on 1.1.1 wrt this change? Can I go ahead and
make these changes?
My reading of Matt's note (which I agree with) is that you should
wait until 1.1.1 has been shipped (unless 1.1.1 runs into an
extended delay in releasing due to administrative matters).
I think this change should follow the RTC process. This is not a
bug fix, not a doc change, etc. It's updating svn and changing the
way we deliver specs -- my read is that it falls under RTC.
I read this as more of a policy discussion as the topic is really,
how do we want to layout specs now and in the future and how do we
branch and tag them on release.
Let's do like we did on this thread: http://marc.theaimsgroup.com/?
l=geronimo-devm=115094116905426w=4
In other words, create a new version of the proposal that's more
detailed and incorporates the feedback from the original, then put
it up for a vote.
Jason, you want the honors?
-David
You don't mention geronimo-j2ee_1.4_spec (the uber-jar). It's
currently versioned using the top-level pom version. I assume you
plan on adding a geronimoSpecsJ2eeVersion?
Your process for updating the jms spec would be:
cd specs/geronimo-spec-jms
mvn release
cd ../geronimo-spec-j2ee
mvn release
I'm not so sure that this is any better than we have now... I see
two options:
1) drop the uber-jar
2) release all specs simultaneosly (even if they haven't changed)
and all have the same version...
--kevan
--jason
On Aug 12, 2006, at 12:16 AM, Matt Hogstrom wrote:
Jason,
I'm +1 on the change. In order to release 1.1.1 we need to
release an updated version of the J2EE_JAAC specs. I am waiting
for feedback from Geir on some licensing issues as well as a TCK
run that Kevan is doing. That said I'd prefer to wait until the
we cut the 1.1.1 release. If it looks like its going to be
delayed due to the licensing concerns then we should do this
straight away next week.
Since this isn't a code change I agree with Jason's comments on
no review required. Lazy consensus is appropriate here.
Jason Dillon wrote:
A while ago there was talks about independently versioning
specs, and Alan started a reorg branch which gives each spec
module its own trunk+branches+tags...
I have been thinking about this for a while, and with the
recent desire to split off more modules from geronimo/trunk
I've been pondering it even more. What I have come to believe
is that spitting up spec modules into their own trunk+branches
+tags is probably not the best direction for us to head in.
I believe that all of our specs can, and should, share one
trunk... and still have each module specify its own version.
This is very similar to how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently.
The top-level pom has a version too, which is independent and
is only changed when there is a major configuration change in
that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check
out and building when you just want all of the specs. If each
spec was in its own trunk, you would need to svn co each one,
then mvn install in each tree, which is a pain.
We also almost never branch specs, they just keep chugging
along, only really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/
trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_,
which we can set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/$
{pom.artifactId}
When released, the plugin will svn cp just the module's
directory into a directory under tags, so it will be easy to
see what the released versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own
trunk, and really I think that if we did then it would just
make it more difficult for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change,
which isn't that major, is that the properties which live in
the root pom that control the versions need to be removed... or
rather moved back to the version element of the respective pom.
Comments?
--jason
Re: Move trunk, tags and branches to server/*
It works great. We've used it in the past for switching to pre- release branches, etc. -David On Aug 16, 2006, at 1:49 AM, Jason Dillon wrote: Maybe... I've never used svn switch before... not sure I would trust it ;-) --jason On Aug 16, 2006, at 1:01 AM, Guillaume Nodet wrote: On 8/16/06, Jason Dillon [EMAIL PROTECTED] wrote: This is a simple change... but will have a large affect on developers, who will need to checkout again. Maybe a svn switch would work ? When is a good time to implement this? --jason On Aug 15, 2006, at 11:18 PM, Guillaume Nodet wrote: +1 On 8/16/06, Jason Dillon [EMAIL PROTECTED] wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 11, 2006, at 2:41 PM, David Blevins wrote: On Aug 9, 2006, at 1:21 AM, David Blevins wrote: I'm going to start a branch tomorrow to experiment with JPA stuff Done. Got a branch up here: - Revision 430900: /geronimo/branches/jpa-plugin Didn't turn out to need this as I'm not changing anything. Going to add the plugins to the sandbox instead and delete the branch I made. -David Also threw up a wiki page: - http://cwiki.apache.org/confluence/display/GMOxSBOX/JPA+Plugin I think I also got Dain roped into helping me with some of the naming parts (bought him breakfast and sprung it on him while he was all in a good mood). We're sitting right next o each other here at a coffee shop so hopefully we can rise to the challenge of keeping stuff on the list. The last idea in my head last night before I went to sleep was that I thought one good approach was to create the PersistenceUnitInfo objects sans their references to DataSources and shove them into a special JNDI Reference object that will pull the DataSource from JNDI and create the EntityManagerFactory and pass that back in the getValue method (or whatever it's called) of the JNDI Reference upon a lookup. The user would still be responsible for configuring the name of the DataSource in the persistence.xml and that the DataSource should come from the right pool (i.e. the non-tx pool). Again, this is for app-managed JPA. Container-managed JPA is another ball of wax. Anyway, more later. -David
openwire command generation
Hey guys I'm trying to understand the openwire command generator. My first task is just getting it to run and generate commands for the current set of clients.. Once I build the broker I attempt to run the generator with Mvn gram:gram from the activemq-core folder. I get tons of errors that look like this: [INFO] [gram:gram] Parsing source files in: [e:\Eclipse\ActiveMQ\activemq-trunk\activemq-core\src\main\java] [INFO] Evaluating Groovy script: GenerateJavaMarshalling.groovy GenerateJavaMarshalling generating files in: src\main\java\org\apache\activemq\openwire\v2 [JAM] Warning: failed to resolve class AsyncCommandChannel [JAM] Warning: failed to resolve class Statistic [JAM] Warning: failed to resolve class MessageListener [JAM] Warning: failed to resolve class QueueSession [JAM] Warning: failed to resolve class Resource [JAM] Warning: failed to resolve class Statistic [JAM] Warning: failed to resolve class JMSException [JAM] Warning: failed to resolve class Queue [JAM] Warning: failed to resolve class Queue [JAM] Warning: failed to resolve class QueueConnectionFactory [JAM] Warning: failed to resolve class QueueConnection [JAM] Warning: failed to resolve class JndiTemplate GenerateJavaMarshalling processing class: LocalTransactionId GenerateJavaMarshalling processing class: PartialCommand GenerateJavaMarshalling processing class: IntegerResponse GenerateJavaMarshalling processing class: ActiveMQQueue Most of the time I end up with a Build Failure with an out of memory exception which looks like the following: [INFO] - [ERROR] FATAL ERROR [INFO] - [INFO] Java heap space [INFO] - [INFO] Trace java.lang.OutOfMemoryError: Java heap space Any clues what is going on here? I need to get this working so that I can go onto trying to get openwire commands generated for activemq-cpp. - Timothy A. Bish
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congratulations Alan! Regards, John Matt Hogstrom wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
Re: [WELCOME] Guillaume Nodet has accepted an invitation to join the Geronimo PMC
Congratulations Guillaume! Regards, John Matt Hogstrom wrote: All, Please join us in welcoming Guillaume who recently accepted an invitation to join the Geronimo PMC. Guillaume is probably best known for his work on Xbean and ServiceMix. Has always been available to help out folks and is a great example of working in the community. He has been a apart of the Geronimo Community for quite some time and we are very excited to have him helping with the project. Give it up for Guillaume. The Apache Geronimo PMC
Re: openwire command generation
Hi Tim, Wild, I just ran it and it was ok. Try setting you MAVEN_OPTS shell variable to something like -Xmx800M Regards, Hiram On 8/17/06, Timothy Bish [EMAIL PROTECTED] wrote: Hey guys I'm trying to understand the openwire command generator. My first task is just getting it to run and generate commands for the current set of clients.. Once I build the broker I attempt to run the generator with Mvn gram:gram from the activemq-core folder. I get tons of errors that look like this: [INFO] [gram:gram] Parsing source files in: [e:\Eclipse\ActiveMQ\activemq-trunk\activemq-core\src\main\java] [INFO] Evaluating Groovy script: GenerateJavaMarshalling.groovy GenerateJavaMarshalling generating files in: src\main\java\org\apache\activemq\openwire\v2 [JAM] Warning: failed to resolve class AsyncCommandChannel [JAM] Warning: failed to resolve class Statistic [JAM] Warning: failed to resolve class MessageListener [JAM] Warning: failed to resolve class QueueSession [JAM] Warning: failed to resolve class Resource [JAM] Warning: failed to resolve class Statistic [JAM] Warning: failed to resolve class JMSException [JAM] Warning: failed to resolve class Queue [JAM] Warning: failed to resolve class Queue [JAM] Warning: failed to resolve class QueueConnectionFactory [JAM] Warning: failed to resolve class QueueConnection [JAM] Warning: failed to resolve class JndiTemplate GenerateJavaMarshalling processing class: LocalTransactionId GenerateJavaMarshalling processing class: PartialCommand GenerateJavaMarshalling processing class: IntegerResponse GenerateJavaMarshalling processing class: ActiveMQQueue Most of the time I end up with a Build Failure with an out of memory exception which looks like the following: [INFO] - [ERROR] FATAL ERROR [INFO] - [INFO] Java heap space [INFO] - [INFO] Trace java.lang.OutOfMemoryError: Java heap space Any clues what is going on here? I need to get this working so that I can go onto trying to get openwire commands generated for activemq-cpp. - Timothy A. Bish -- Regards, Hiram Blog: http://hiramchirino.com
ActiveMQ 4.x in Geronimo
Hey guys can one of you spare a few cycles to help me to get the ActiveMQ integration sorted using 4.x in G 1.2/trunk? Thanks, --jason
[jira] Commented: (GERONIMO-1722) Module migration to Maven 2: activemq-embedded-rar
[ http://issues.apache.org/jira/browse/GERONIMO-1722?page=comments#action_12428852 ] Jason Dillon commented on GERONIMO-1722: This patch is not valid... does not apply cleanly to trunk... and I can't find these deps in a m2 repo, only m1, which does not have transitive deps. I'm trying to figure out where the new 4.x artifacts are published, and will update the activemq modules when I find them. I'm keeping this issue opened so that once I find them I can make sure to get these excludes in there. Module migration to Maven 2: activemq-embedded-rar -- Key: GERONIMO-1722 URL: http://issues.apache.org/jira/browse/GERONIMO-1722 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 1.x Reporter: Jacek Laskowski Assigned To: Jason Dillon Attachments: GERONIMO-1722.patch It's a task to help keep track of the progress of the module build migration to Maven2 -- 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
Remove module: installer-support
Since we are not going to put any effort into getting the izpack installer back up in trunk/1.2 right now, I'd like to remove this module. If needed we can always resurrect it later. Objections? --jason
Re: Remove module: installer-support
Go for it. Are you going to move it to the island of mis-fit toys? Remember that Rudolph saved them :) Jason Dillon wrote: Since we are not going to put any effort into getting the izpack installer back up in trunk/1.2 right now, I'd like to remove this module. If needed we can always resurrect it later. Objections? --jason
Re: Remove module: installer-support
Eh, you mean the box-o-sand? I can though my guess is that they will just fester in there and attract flies. --jason On Aug 17, 2006, at 6:50 PM, Matt Hogstrom wrote: Go for it. Are you going to move it to the island of mis-fit toys? Remember that Rudolph saved them :) Jason Dillon wrote: Since we are not going to put any effort into getting the izpack installer back up in trunk/1.2 right now, I'd like to remove this module. If needed we can always resurrect it later. Objections? --jason
Re: Remove module: installer-support
Or, create a JIRA and post their demise and the revision number? Not sure how this is normally handled. Just looking for how someone might resurrect the beast later. Our box-o-sand in the backyard attracts cats...lucky you only have flies ;-P Jason Dillon wrote: Eh, you mean the box-o-sand? I can though my guess is that they will just fester in there and attract flies. --jason On Aug 17, 2006, at 6:50 PM, Matt Hogstrom wrote: Go for it. Are you going to move it to the island of mis-fit toys? Remember that Rudolph saved them :) Jason Dillon wrote: Since we are not going to put any effort into getting the izpack installer back up in trunk/1.2 right now, I'd like to remove this module. If needed we can always resurrect it later. Objections? --jason
[jira] Commented: (GERONIMO-2299) Unpack assemblies for easier development/testing
[ http://issues.apache.org/jira/browse/GERONIMO-2299?page=comments#action_12428864 ] Jason Dillon commented on GERONIMO-2299: So, Java sucks when it comes to file perms... even if we unzip or untgz these files, they will *NOT* have the correct permissions. Not sure there is much we can do about this except for add an external script and/or shell out to execute that script from antrun... sucks. Unpack assemblies for easier development/testing Key: GERONIMO-2299 URL: http://issues.apache.org/jira/browse/GERONIMO-2299 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Jason Dillon Assigned To: Jason Dillon Priority: Minor Should unpack the assemblies (or a given assembly) automatically to help ease development. Probably just need to add a new profile that will use antrun to unzip the archive. -- 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-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] Matt Hogstrom updated GERONIMO-2307: If we need to create these then create these we must. Here are the files that I know of in our development tree that need to have substitutes created. Not sure if they exist or not. I took the files and found their location in the source tree to make finding them easier. I've modified the description with the files and using the nice markup we have I placed them in the description of this JIRA. Volunteers welcome :) 1.1.1 and other releases are stalled until we get this resolved. Geir, how does this impact previous releases of Geronimo? Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Geir Magnusson Jr Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. -- 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: Remove module: installer-support
Well, I defs don't want cats in there... its not a litterbox... and partly why I'm hesitant to toss stuff in there... after a while it might start to smell bad. I think it is reasonable to create an issue to state its going to be dropped, then let the JIRA svn plugin link to it from the comment in the change. --jason On Aug 17, 2006, at 7:07 PM, Matt Hogstrom wrote: Or, create a JIRA and post their demise and the revision number? Not sure how this is normally handled. Just looking for how someone might resurrect the beast later. Our box-o-sand in the backyard attracts cats...lucky you only have flies ;-P Jason Dillon wrote: Eh, you mean the box-o-sand? I can though my guess is that they will just fester in there and attract flies. --jason On Aug 17, 2006, at 6:50 PM, Matt Hogstrom wrote: Go for it. Are you going to move it to the island of mis-fit toys? Remember that Rudolph saved them :) Jason Dillon wrote: Since we are not going to put any effort into getting the izpack installer back up in trunk/1.2 right now, I'd like to remove this module. If needed we can always resurrect it later. Objections? --jason
Re: Remove module: installer-support
Or we can make a litterbox as a peer to the sandbox, then get the scooper out quarterly and toss the undesirables. I don't care too much... just want it out of trunk. --jason On Aug 17, 2006, at 7:07 PM, Matt Hogstrom wrote: Or, create a JIRA and post their demise and the revision number? Not sure how this is normally handled. Just looking for how someone might resurrect the beast later. Our box-o-sand in the backyard attracts cats...lucky you only have flies ;-P Jason Dillon wrote: Eh, you mean the box-o-sand? I can though my guess is that they will just fester in there and attract flies. --jason On Aug 17, 2006, at 6:50 PM, Matt Hogstrom wrote: Go for it. Are you going to move it to the island of mis-fit toys? Remember that Rudolph saved them :) Jason Dillon wrote: Since we are not going to put any effort into getting the izpack installer back up in trunk/1.2 right now, I'd like to remove this module. If needed we can always resurrect it later. Objections? --jason
Re: Release schedule
On 8/17/06, Vadim Pesochinsky [EMAIL PROTECTED] wrote: I am wondering what would be the estimate date for 4.1 release? Do we have an idea of when and what releases are going to happen? How many more 4.0.x releases will we have? Now that 4.0.2 is pretty much out (the vote on the Incubator PMC looks just about done) I think we're close to cutting our first release of 4.1 as the code's looking in good shape. So maybe a week or so for the first release candidate build then if that's OK about another week or so to get it through the voting process -- James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] Matt Hogstrom updated GERONIMO-2307: Description: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| was: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. Include appropriate license for the Sun j2ee schema files that are redistributed
Re: Where is the source code for the G samples ?
Where in tomcat? Got a SVN URL handy? --jason On Aug 16, 2006, at 12:47 PM, Dave Colasurdo wrote: We grabbed the jars from Tomcat, unpacked them and manually made a few changes to them (outside of source control) and published the resulting wars. Here is the description of the manual changes: http://issues.apache.org/jira/browse/GERONIMO-1299 -Dave- Matt Hogstrom wrote: Aaron, Its soming clearer now...I think we grabbed the jars straight from Tomcat. Aaron Mulder wrote: On 8/16/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I think they were removed from Geronimo as part of the plugins work. Aaron provides the samples as plugins now. Perhaps we need to have them in G as well due to the issues you are tracking. I think it made sense to move them previously but sounds like there are reasons to keep them in both places. Nope. I just took them out of the assemblies. I didn't change the way that they were built, other than to add the geronimo- plugin.xml to the various config/ modules. I've never seen the source for these examples. Didn't the JARs just pop off of Zeus' leg or something? Thanks, Aaron Prasad Kashyap wrote: Does anybody know where I can find the source code for the geronimo samples, jsp-examples and tomcat-examples ? We are using these in our builds from this repository http://people.apache.org/repo/m1-snapshot-repository/geronimo- samples/wars/ We should archive the classes dirs in these wars just like we do to the apps in our build. When these examples wars are used in our build as is, there is a good possibility that it might hit the long path limit on windows. Cheers Prasad
[jira] Commented: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=comments#action_12428875 ] Jason Dillon commented on GERONIMO-2307: Its so dumb that we have to rewrite these... when to be compliant they need to be identical... content-wise that is. Why the heck does sun do this... just more work to be compliant and increases the changes that they won't be... :-( Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Geir Magnusson Jr Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| -- 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: Remove module: installer-support
Litterbox sounds like the right name...although JIRA linking is probably more appropriate. You have my vote. Jason Dillon wrote: Or we can make a litterbox as a peer to the sandbox, then get the scooper out quarterly and toss the undesirables. I don't care too much... just want it out of trunk. --jason On Aug 17, 2006, at 7:07 PM, Matt Hogstrom wrote: Or, create a JIRA and post their demise and the revision number? Not sure how this is normally handled. Just looking for how someone might resurrect the beast later. Our box-o-sand in the backyard attracts cats...lucky you only have flies ;-P Jason Dillon wrote: Eh, you mean the box-o-sand? I can though my guess is that they will just fester in there and attract flies. --jason On Aug 17, 2006, at 6:50 PM, Matt Hogstrom wrote: Go for it. Are you going to move it to the island of mis-fit toys? Remember that Rudolph saved them :) Jason Dillon wrote: Since we are not going to put any effort into getting the izpack installer back up in trunk/1.2 right now, I'd like to remove this module. If needed we can always resurrect it later. Objections? --jason
G ActiveMQ 4
We still need to finish getting the 4.x series into the server. I think this is a must for 1.2. The AMQ folks are close to releasing 4.1, which is the first release that is using m2 and has m2 artifacts. I think we should switch over trunk to use the 4.1- SHAPSHOT and then 4.1 when they get the release out. Still need to get those gbeans hooked up that Hiram added too, they are not included in the assembly, though we are building them. Any objections to getting 4.1[-SNAPSHOT] in sometime soonish (week or so)? --jason
