RE: Regarding feedback on OpenWire C++ client
Hi Hiram, 5) .NET namespace Hiram, what rules does Apache imply on this? Is it ok to use the namespaces your giving examples on? Looking on the Java code all Apache code starts with org.apache. As far as I know the org.apache namespace is a Java thing as it's the only language the encourages that form. I've never seen this form use in other languages yet. Even so it might be better to be a bit overzealous to prevent namespace clashes :) If ASF does not have any rules about this we'll change it - no problem. However, if we're to sync the names between C# and C++ the C# name spaces should be altered also!? C# namespace cms namespace activemq.command namespace activemq.core namespace activemq.io C++ namespace cms namespace activemq::command namespace activemq::io namespace activemq::marshal namespace activemq::protocol namespace activemq::transport namespace activemq::util Regards, Mats
Re: ActiveMQ client for J2ME
Awesome stuff BTW Ian - I'd *love* a J2ME Stomp/ActiveMQ client :) BTW the correlation-id is the Stomp-approved name for passing along the correlationID; in JMS-land its really a property called JMSCorrelationID, so changing your selector header to activemq.selector:JMSCorrelationID= '11143353544334-0' Should do the trick I think. I confess this renaming of JMSCorrelationID - correlation-id in Stomp could be a bit confusing for folks; maybe it'd be better if we let folks keep the regular JMS* style headers? (It'd be easy to support both BTW) James Ian de Beer wrote: Hi I have developed a J2ME client for ActiveMQ using the Stomp protocol. I would be happy to contribute this to the project, but I have a real show stopper issue that I cannot seem to resolve. I use it in a request/response mode with the request and subscription looking like this: SEND destination:/queue/Mobile.Queue reply-to:/queue/Temp.Queue correlation-id:11143353544334-0 ?xml version='1.0' encoding='UTF8' ?requestidloginValidation/ idbeaneFileHandler/beanmethodloginValidation/ methodparamspasswordabc/passwordusernameian/username/ params/request ^@ and : SUBSCRIBE destination:/queue/Temp.Queue activemq.selector:correlation-id = '11143353544334-0' ack:client ^@ Despite various permutations of correlation-id and selector settings, the clients keep consuming each others messages. Could someone please tell me what the Stomp syntax is for selecting messages with a specific correlation-id from the queue. Regards Ian -- View this message in context: http://www.nabble.com/ActiveMQ-client-for-J2ME-t1354154.html#a3627782 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Regarding feedback on OpenWire C++ client
On 3/28/06, David Fahlander [EMAIL PROTECTED] wrote:
Hi Nathan,
1) Use of smart pointers.
Though the user interface would be cleaner without smart pointers
they
serves a purpose even when the passed in object is not owned by the
client.
As soon as an object is shared between two classes you have the
problem when the object should be deleted - this problem is
eliminated
when using SP's, the object is deleted when both object releases its
reference to it.
I'm not sure I agree. For user-generated objects, it should be up to
the user to
add and remove references to them across the openwire library (such as
references
to IMessageListeners). When the user passes in a reference to one of
his objects,
he's not expecting to give any amount of lifetime control to the
openwire code.
In fact, the user object may not even have been created on the heap,
it may be a
local variable that was added just for the scope of a function. In
this case,
when the openwire library decides to delete it, the application blows
up! We
have to make a separation of what is and what is not under our
library's control.
We can't assume a structure of the client code, this forces the client
into a
particular way of programming and causes our client to become a burden
to the
developer and will turn them off to using ActiveMQ.
Regarding objects that the user provides, we still get benefits by using
smart pointers for them. It is not always the creator that is
responsible of deletion. Especially in a threaded application it can be
important to not end-up with ghost pointers. A thread in our client
library that holds a pointer to a listener, must be able to rely on that
the instance is still alive as long as it holds the SP to it. If the
user would provide an ordinary pointer, the user must never delete it as
long as there might be threads in our library using it. What about
static objects that should last forever in the client's lifetime then?
Still, we want to be able to take down the client in a controlled way.
Doing that without smart pointers, may create a lot of problems in our
experience.
The burden for the user would only lie in the classes that implement
our interfaces. If our API requires a pIMessageListener, the user must
hold his message listener using a pMyMessageListener allocated with
new MyMessageLister (...);. The user does not have to let this affect
his design. If the user wants, this instance can lie as a member within
another class that is neither derived from our interface nor maintained
as a smart pointer.
You get no benefits at all by adding smart pointers to the interface. The
user will delete their objects whenever they wish, regardless of what the
openwire library does ... and if it does so, the openwire library will
explode as soon as it tries to reference it. That's the thing - this is C++
and there is no mechanism to prevent someone from coding badly, and adding
smart pointers to the API isn't going to change that. The user is
responsible for both adding and removing referenes to its objects. And it's
not the job of the openwire lib to worry about memory management in the
user-domain - it should only be concerned with its own memory management.
In addition, smart pointers are assuming that the object is allocated on the
heap, as it will do a delete when the last reference is removed. This is
wrong, because the user should be able allocate its objects in whatever way
makes sense for the application.
Also, adding smart pointer arguments to all the methods on the api makes it
complicated and ugly. If the openwire library wants to use smart pointers
internally, that's fine, but it shouldn't impose the use of smart pointers
on the user. It's our job to make the user's experience a good one so they
continue to use ActiveMQ in their applications.
SP's and Strings: Semi-agreed :) The setters should all have const
char*
but we could change the getters to std:string (without SP), then it
is
up to the user to either use it as a std:string or a const char*.
I think symmetry is a good thing. We should pick one way or the other
...
either both the getter and setter take const char* or they both take
strings.
Also, when passing strings around, they should be passed as const
std::string ...
this way you don't have to copy the entire string, you just pass a
constant reference
to it. This will save a lot of processing when dealing with large
text messages, for
example.
The options we have regarding passing and holding strings are the
following:
Class Xxx {
pstring name;
public:
void setName (pstring name) {
this-name = name;
}
pstring getName () {
return this-name;
}
pstring createName() {
return new string (name: + *name);
}
};
In the above example, strings are never copied, just the ptr value. The
downside is that the caller needs to pass their strings as
[jira] Created: (AMQ-666) enable RESTful browsing of message queues using a web connector - either as message IDs or as XML or as RSS/Atom
enable RESTful browsing of message queues using a web connector - either as message IDs or as XML or as RSS/Atom Key: AMQ-666 URL: https://issues.apache.org/activemq/browse/AMQ-666 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Assigned to: james strachan Fix For: 4.0 RC 2 -- 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: Regarding feedback on OpenWire C++ client
Nate,
You get no benefits at all by adding smart pointers to the interface.
The user will delete their objects whenever they wish, regardless of
what the openwire library does ... and if it does so, the openwire
library will explode as soon as it tries to reference it. That's the
thing - this is C++ and there is no mechanism to prevent someone from
coding badly, and adding smart pointers to the API isn't going to change
that. The user is responsible for both adding and removing referenes to
its objects. And it's not the job of the openwire lib to worry about
memory management in the user-domain - it should only be concerned with
its own memory management.
In addition, smart pointers are assuming that the object is allocated on
the heap, as it will do a delete when the last reference is removed.
This is wrong, because the user should be able allocate its objects in
whatever way makes sense for the application.
Also, adding smart pointer arguments to all the methods on the api makes
it complicated and ugly. If the openwire library wants to use smart pointers
internally, that's fine, but it shouldn't impose the use of smart pointers
on the user. It's our job to make the user's experience a good one so they
continue to use ActiveMQ in their applications.
Please define the interfaces that you want to be SP-free!
It's all about the user and helping them come up to speed and use the api
as quickly and painlessly as possible. I understand that in these cases
you're passing a pointer and not copying, but it complicates the user
interface when the person just wants to pass in a string. They shouldn't
have to create a string on the heap an then wrap it in a smart pointer to
just call a function.
Just a quick note, this is not necessary with the current design of accepting
const char* and returning pstring. The user can easily extract the const
char from the SP string if wanted.
Class Xxx {
std::string name;
void setName (const std::string name) {
this-name = name;
}
const std::string getName () const {
return this-name;
}
};
Shall we agree on the one above?
Regards,
Mats David
[jira] Resolved: (AMQ-666) enable RESTful browsing of message queues using a web connector - either as message IDs or as XML or as RSS/Atom
[ https://issues.apache.org/activemq/browse/AMQ-666?page=all ] james strachan resolved AMQ-666: Resolution: Fixed For details see: http://docs.codehaus.org/display/ACTIVEMQ/RSS+and+Atom enable RESTful browsing of message queues using a web connector - either as message IDs or as XML or as RSS/Atom Key: AMQ-666 URL: https://issues.apache.org/activemq/browse/AMQ-666 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Assignee: james strachan Fix For: 4.0 RC 2 -- 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: ActiveMQ client for J2ME
BTW in 4.x I think the Stomp syntax for a selector is selector rather than activemq.selector though the latter will probably work too http://activemq.codehaus.org/Stomp -- View this message in context: http://www.nabble.com/ActiveMQ-client-for-J2ME-t1354154.html#a3628451 Sent from the ActiveMQ - Dev forum at Nabble.com.
RE: Regarding feedback on OpenWire C++ client
Please define the interfaces that you want to be SP-free!
I'm with Hiram ... I think the entire API should be SP-free. The less
the users have to see SPs, the better.
It's all about the user and helping them come up to speed and use the
api
as quickly and painlessly as possible. I understand that in these
cases
you're passing a pointer and not copying, but it complicates the user
interface when the person just wants to pass in a string. They
shouldn't
have to create a string on the heap an then wrap it in a smart pointer
to
just call a function.
Just a quick note, this is not necessary with the current design of
accepting const char* and returning pstring. The user can easily
extract the const char from the SP string if wanted.
But then you lose the symmetry of the getters and setters ... the setter
should take the same type that the getter returns. IMHO, it seems
strange to have the setter take a char* and then the getter returns a
smart pointer.
Class Xxx {
std::string name;
void setName (const std::string name) {
this-name = name;
}
const std::string getName () const {
return this-name;
}
};
Shall we agree on the one above?
Regards,
Mats David
Regards,
Nate
[jira] Created: (AMQ-667) fix SslTransportBrokerTest
fix SslTransportBrokerTest -- Key: AMQ-667 URL: https://issues.apache.org/activemq/browse/AMQ-667 Project: ActiveMQ Type: Test Components: Test Cases Reporter: james strachan Assigned to: Adrian Co -- 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: Regarding feedback on OpenWire C++ client
On 3/28/06, Mats Forslöf [EMAIL PROTECTED] wrote: Hi Hiram, Even so it might be better to be a bit overzealous to prevent namespace clashes :) I would like to make this c++ lib, feel very c++ like, I don't want it to smell like it came from a Java shop. So I think it's better to have short names like most of the other libs out there. If ASF does not have any rules about this we'll change it - no problem. However, if we're to sync the names between C# and C++ the C# name spaces should be altered also!? C# namespace cms namespace activemq.command namespace activemq.core namespace activemq.io No.. becaue the C# one alos works for VB.NET and J# etc. etc. that's why the interface are in the .NET Message Service (NMS) namespace. Also .Net uses Camel case convention in it's namespaces. So we will do it like that. Once again the aim is to have a .NET library the feels very native. C++ namespace cms namespace activemq::command namespace activemq::io namespace activemq::marshal namespace activemq::protocol namespace activemq::transport namespace activemq::util This looks good to me! Regards, Mats -- Regards, Hiram
Re: [Heads up] new visualisation plugin available
I've just completed a second, more impressive visualisation that shows all the connections on a broker together with the producers and consumers, showing the flow of connection - producer - destination - subscriber - connection. http://docs.codehaus.org/display/ACTIVEMQ/Visualisation To minimise noise I've left off the actual session objects from the graph; you can kinda figure that out by the numbers in each producer/consumer (the first number is the session and the second the producer/consumer number) James On 3/27/06, James Strachan [EMAIL PROTECTED] wrote: On 3/27/06, OG [EMAIL PROTECTED] wrote: Very nice. Put some IP addresses there and refresh the DOT file periodically with some numbers/stats, and I'll start drooling. You read my mind :) So right now this DOT file is real time; every time a destination is added/removed we regenerate the DOT file. So using the OS X tool, we get a real time graphical view. (We could hopefully add a kinda web/ajax client on top of this to get real time visualisations on the management portal too). The part I really want us to do is to graphically represent how connections, sessions, consumers producers relate to brokers destinations within the brokers; together with stats. There's a ton of useful visualisations we can do - our only limitation here is our imagination. I've put together a visualisation wish list wiki page... http://docs.codehaus.org/display/ACTIVEMQ/Visualisation+Wish+List please if you can think of any interesting ideas for what we could visualise or how it could look, please add a note. Better still try patch the code to do it :) BTW if you are interested - here's the code for the real time rendering of the destination hierarchies http://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/view/ as you can see its pretty simple stuff; we've a ton of stats and information inside the broker that it'll be really easy to render as some kind of picture -- James --- http://radio.weblogs.com/0112098/ -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (AMQ-668) Build is broken - missing the rome_version and the jdom_version
Build is broken - missing the rome_version and the jdom_version --- Key: AMQ-668 URL: https://issues.apache.org/activemq/browse/AMQ-668 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Bruce Snyder Attachments: project.properties.diff + | Executing clean ActiveMQ :: Web | Memory: 6M/9M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download rome-.jar. WARNING: Failed to download rome-.jar. Attempting to download jdom-.jar. WARNING: Failed to download jdom-.jar. BUILD FAILED File.. /Users/bsnyder/.maven/cache/maven-multiproject-plugin-1.4.1/plugin.jelly Element... maven:reactor Line.. 218 Column -1 The build cannot continue because of the following unsatisfied dependencies: rome-.jar jdom-.jar Total time : 1 minutes 21 seconds Finished at : Tuesday, March 28, 2006 1:51:36 PM MST -- 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] Updated: (AMQ-668) Build is broken - missing the rome_version and the jdom_version
[ https://issues.apache.org/activemq/browse/AMQ-668?page=all ] Bruce Snyder updated AMQ-668: - Attachment: project.properties.diff Build is broken - missing the rome_version and the jdom_version --- Key: AMQ-668 URL: https://issues.apache.org/activemq/browse/AMQ-668 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Bruce Snyder Attachments: project.properties.diff + | Executing clean ActiveMQ :: Web | Memory: 6M/9M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download rome-.jar. WARNING: Failed to download rome-.jar. Attempting to download jdom-.jar. WARNING: Failed to download jdom-.jar. BUILD FAILED File.. /Users/bsnyder/.maven/cache/maven-multiproject-plugin-1.4.1/plugin.jelly Element... maven:reactor Line.. 218 Column -1 The build cannot continue because of the following unsatisfied dependencies: rome-.jar jdom-.jar Total time : 1 minutes 21 seconds Finished at : Tuesday, March 28, 2006 1:51:36 PM MST -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-669) Add a keepDurableSubsActive option to brokers so that durable subs eagerly loaded and kept in memory
Add a keepDurableSubsActive option to brokers so that durable subs eagerly loaded and kept in memory Key: AMQ-669 URL: https://issues.apache.org/activemq/browse/AMQ-669 Project: ActiveMQ Type: Improvement Components: Broker Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.0 RC 2 Problem is described at: https://issues.apache.org/activemq/browse/AMQ-493 One way to solve this is to avoid getting to the big backlog of messages. The there are not too many messages to recover, then AMQ-493 is not an issue. Add a keepDurableSubsActive option to the broker would be a workaround to this issue. The down side is that the broker would eventually block if the durable consumer is offline for too long. -- 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] Updated: (SM-370) wsa:MessageID is not implemented for WS-Addressing
[ https://issues.apache.org/activemq/browse/SM-370?page=all ] Guillaume Nodet updated SM-370: --- Component: servicemix-jms Fix Version: 3.0-M1 Assign To: Guillaume Nodet wsa:MessageID is not implemented for WS-Addressing -- Key: SM-370 URL: https://issues.apache.org/activemq/browse/SM-370 Project: ServiceMix Type: Improvement Components: servicemix-http, servicemix-jms Versions: incubation Reporter: Tomas Olsson Assignee: Guillaume Nodet Priority: Minor Fix For: 3.0-M1 -- 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-370) wsa:MessageID is not implemented for WS-Addressing
[ https://issues.apache.org/activemq/browse/SM-370?page=all ] Guillaume Nodet resolved SM-370: Resolution: Fixed Author: gnodet Date: Tue Mar 28 02:46:44 2006 New Revision: 389472 URL: http://svn.apache.org/viewcvs?rev=389472view=rev Log: SM-370: wsa:MessageID is not implemented for WS-Addressing Added: incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/AddressingHandler.java - copied, changed from r387168, incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/AddressingInHandler.java Removed: incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/AddressingInHandler.java Modified: incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/processors/ConsumerProcessor.java incubator/servicemix/trunk/servicemix-http/src/test/java/org/apache/servicemix/http/HttpAddressingTest.java incubator/servicemix/trunk/servicemix-http/src/test/resources/org/apache/servicemix/http/addressing-request.xml incubator/servicemix/trunk/servicemix-jms/src/main/java/org/apache/servicemix/jms/MultiplexingConsumerProcessor.java incubator/servicemix/trunk/servicemix-soap/project.xml incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/Context.java incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/Handler.java incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/SoapHelper.java incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/handlers/AbstractHandler.java wsa:MessageID is not implemented for WS-Addressing -- Key: SM-370 URL: https://issues.apache.org/activemq/browse/SM-370 Project: ServiceMix Type: Improvement Components: servicemix-http, servicemix-jms Versions: incubation Reporter: Tomas Olsson Assignee: Guillaume Nodet Priority: Minor Fix For: 3.0-M1 -- 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] Updated: (SM-344) Improve clustering by allowing implicit endpoint selection to be done by the flow
[ https://issues.apache.org/activemq/browse/SM-344?page=all ] Guillaume Nodet updated SM-344: --- Fix Version: (was: 3.0-M2) Improve clustering by allowing implicit endpoint selection to be done by the flow - Key: SM-344 URL: https://issues.apache.org/activemq/browse/SM-344 Project: ServiceMix Type: Improvement Components: servicemix-core Reporter: Guillaume Nodet We should create one queue per interface and service, so that the load-balancing would be more effective when targeting an interface. This will require to move the endpoint resolution to the flows instead of the broker. -- 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] Updated: (SM-326) Disable tests using an external soap server
[ https://issues.apache.org/activemq/browse/SM-326?page=all ] Guillaume Nodet updated SM-326: --- Fix Version: (was: 3.0-M2) Disable tests using an external soap server --- Key: SM-326 URL: https://issues.apache.org/activemq/browse/SM-326 Project: ServiceMix Type: Test Components: servicemix-components Reporter: Guillaume Nodet org.apache.servicemix.components.saaj.SaajTest org.apache.servicemix.components.http.HttpTest org.apache.servicemix.components.http.HttpSoapTest org.apache.servicemix.components.http.HttpSoapAndSaajTest Need to put something like a mock component to simulate this request. -- 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] Updated: (SM-292) Add a toDOMElement method to SourceTransformer and check all calls to toDOMNode for possible CCE
[ https://issues.apache.org/activemq/browse/SM-292?page=all ] Guillaume Nodet updated SM-292: --- Fix Version: (was: 3.0-M2) Add a toDOMElement method to SourceTransformer and check all calls to toDOMNode for possible CCE Key: SM-292 URL: https://issues.apache.org/activemq/browse/SM-292 Project: ServiceMix Type: Improvement Components: servicemix-core, servicemix-components Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-164) use XBean to improve configuration of the standard ServiceMix components like filePoller fileWriter etc
[ https://issues.apache.org/activemq/browse/SM-164?page=all ] Guillaume Nodet updated SM-164: --- Fix Version: (was: 3.0) use XBean to improve configuration of the standard ServiceMix components like filePoller fileWriter etc --- Key: SM-164 URL: https://issues.apache.org/activemq/browse/SM-164 Project: ServiceMix Type: Improvement Components: servicemix-components Reporter: james strachan Assignee: Guillaume Nodet add the @org.xbean.XBean annotations to the various components and port the XML over to use a more pure XBean style to simplify the XML -- 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] Updated: (SM-144) Transactional delivery on jca flow should be configured on the activation spec
[ https://issues.apache.org/activemq/browse/SM-144?page=all ] Guillaume Nodet updated SM-144: --- Fix Version: (was: 3.0) Transactional delivery on jca flow should be configured on the activation spec -- Key: SM-144 URL: https://issues.apache.org/activemq/browse/SM-144 Project: ServiceMix Type: Improvement Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-91) Container does not call init() on initialization
[ https://issues.apache.org/activemq/browse/SM-91?page=all ] Guillaume Nodet updated SM-91: -- Fix Version: (was: 3.0) Container does not call init() on initialization Key: SM-91 URL: https://issues.apache.org/activemq/browse/SM-91 Project: ServiceMix Type: Bug Components: servicemix-core Reporter: George Gastaldi When registering a container, the init() method should be called. Registering a component using Pure Spring makes the component register BEFORE initializing the container and gives the following exception: java.lang.NullPointerException at org.servicemix.jbi.management.ManagementContext.getRelativeName(ManagementContext.java:410) at org.servicemix.jbi.management.ManagementContext.createObjectName(ManagementContext.java:390) at org.servicemix.jbi.container.JBIContainer.activateComponent(JBIContainer.java:881) at org.servicemix.jbi.container.JBIContainer.activateComponent(JBIContainer.java:844) at org.servicemix.jbi.container.JBIContainer.activateComponent(JBIContainer.java:806) at org.servicemix.jbi.container.JBIContainer.activateComponent(JBIContainer.java:754) -- 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] Updated: (SM-98) Component tries to send a message to a service BEFORE registered
[ https://issues.apache.org/activemq/browse/SM-98?page=all ] Guillaume Nodet updated SM-98: -- Fix Version: (was: 3.0) Component tries to send a message to a service BEFORE registered Key: SM-98 URL: https://issues.apache.org/activemq/browse/SM-98 Project: ServiceMix Type: Bug Components: servicemix-components Versions: 1.1 Reporter: George Gastaldi If you register a component, and that immediately sends a message to a not already registered component, an error occurs. If sleeping until all components are registered, everything is ok. However, this is a problem, because when init() is called, it is already supposed that all the components were registered. TIP: This issue can be solved by making the container call init() only when all the services were configured. Thx ! -- 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] Updated: (SM-270) XsltComponent should easily allow for dynamically determining the Xslt during runtime
[ https://issues.apache.org/activemq/browse/SM-270?page=all ] Guillaume Nodet updated SM-270: --- Fix Version: (was: 3.0) XsltComponent should easily allow for dynamically determining the Xslt during runtime - Key: SM-270 URL: https://issues.apache.org/activemq/browse/SM-270 Project: ServiceMix Type: Improvement Components: servicemix-components Versions: 3.0 Reporter: Jeff Puro Priority: Minor Original Estimate: 1 hour Remaining: 1 hour Currently the XsltComponent does not allow for easily pulling the xslt out from a database or datastore. There should be a method that can be overriden that will allow for such functionality. Also, whenever the transformation occurs it should call this method to pull out the latest xslt dynamically. -- 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-145) Non transactional syncSend should be handled by jms / jca flows
[ https://issues.apache.org/activemq/browse/SM-145?page=all ] Guillaume Nodet resolved SM-145: Fix Version: 3.0-M1 Assign To: Guillaume Nodet Resolution: Fixed JMS flow already handles non transactional syncSend Non transactional syncSend should be handled by jms / jca flows --- Key: SM-145 URL: https://issues.apache.org/activemq/browse/SM-145 Project: ServiceMix Type: Improvement Components: servicemix-core Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.0-M1 -- 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] Work stopped: (SM-158) Management application
[ https://issues.apache.org/activemq/browse/SM-158?page=all ] Work on SM-158 stopped by Guillaume Nodet Management application -- Key: SM-158 URL: https://issues.apache.org/activemq/browse/SM-158 Project: ServiceMix Type: New Feature Reporter: Guillaume Nodet Assignee: Guillaume Nodet Manage components Manage service assemblies Statistics view Auditing capabilities Portlet based to be easily integrated into geronimo ? -- 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-163) Allow mixing different NMR flow types in single container instance
[ https://issues.apache.org/activemq/browse/SM-163?page=all ] Guillaume Nodet resolved SM-163: Resolution: Duplicate Allow mixing different NMR flow types in single container instance -- Key: SM-163 URL: https://issues.apache.org/activemq/browse/SM-163 Project: ServiceMix Type: New Feature Reporter: Peter Smith Priority: Minor Current flow type seems fixed per container instance / Broker using the container flowName property. So it seems mixing flow types currently means multiple JBI container instances are needed. Have some way of allowing the flow type to change within a single container instance - eg maybe according to a component property or whatever. -- 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: Why wrap a WebServiceContainer with a StoredObject?
Hi David, On 27 Mar 2006, at 22:28, David Jencks wrote: I think what you will need to do is to write new gbeans for celtix. That will let you store the necessary information in the gbeans in an optimal-for-celtix way. In particular I suspect that you may want to wrap the transport in a gbean and provide a gbean reference from the web service gbean (that I'm telling you to write 2 of, one for jetty and one for tomcat) to that transport gbean. When the web service gbean starts, it can construct whatever it needs to from its attributes and references and in particular insert the transport into whatever other data structures need it. Hope this makes at least minimal sense :-) Makes sense. I thought it was something to do with the classloader. It's not a big problem: I can gather the required information in the builder and defer the construction of the Celtix transport until the WebServiceContainer GBean activates. thanks for the info Conrad
Re: Why wrap a WebServiceContainer with a StoredObject?
On 27 Mar 2006, at 22:55, David Blevins wrote: On Mar 27, 2006, at 1:34 PM, Dain Sundstrom wrote: I thought this ugly hack was necessary to get around the web class loader being a different class loader than the configuration class loader. IIRC the trick was to leave the object as a byte array until the actual web class loader was passed in via the TCCL and then deserialized. That's the reason. Here is the related commit, though your description is better than my commit message: http://svn.apache.org/viewcvs.cgi?rev=157992view=rev Ok that make sense. I can rejig things to avoid the serialization and activate the required Celtix bits later. thanks Conrad
[jira] Created: (GERONIMO-1782) Properties File Login module fails after editing through Admin Console
Properties File Login module fails after editing through Admin Console
--
Key: GERONIMO-1782
URL: http://issues.apache.org/jira/browse/GERONIMO-1782
Project: Geronimo
Type: Bug
Versions: 1.0, 1.1, 1.2
Environment: Win XP, Sun JDK 1.4.2_08
Reporter: Vamsavardhana Reddy
Fix For: 1.1, 1.2
Geronimo-properties-realm fails to initialize after editing the realm thru
Admin Console.
Steps to reproduce the problem.
1. Open the Security Realms portlet in Admin Console.
2. Click on edit link provided next to geronimo-properties-realm.
3. Click on Save button in the next page. PS: No need to edit anything in
this page.
4. Restart the server.
5. Access Admin Console to notice that the realm nolonger works.
NOTE: To make the realm work again, stop the server and remove the following
xml fragment from var/config/config.xml
gbean
name=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0/car,J2EEServer=geronimo,j2eeType=LoginModule,name=properties-login
attribute name=options{usersURI=var/security/users.properties,
groupsURI=var/security/groups.properties}/attribute
attribute name=serverSideTrue/attribute
attribute name=wrapPrincipalsFalse/attribute
attribute
name=loginModuleClassorg.apache.geronimo.security.realm.providers.PropertiesFileLoginModule/attribute
/gbean
At step 5, the following exception is logged to geronimo.log.
13:53:41,950 ERROR [PropertiesFileLoginModule] Initialization failed
java.lang.IllegalArgumentException: Both usersURI and groupsURI must be
provided!
at
org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.initialize(PropertiesFileLoginModule.java:77)
at
org.apache.geronimo.security.jaas.server.JaasLoginService.getServerLoginCallbacks(JaasLoginService.java:205)
at
org.apache.geronimo.security.jaas.server.JaasLoginService$$FastClassByCGLIB$$95b84fc9.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.security.jaas.server.JaasLoginServiceMBean$$EnhancerByCGLIB$$7dca63e6.getServerLoginCallbacks(generated)
at
org.apache.geronimo.security.jaas.client.ServerLoginProxy.login(ServerLoginProxy.java:68)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.performLogin(JaasLoginCoordinator.java:189)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.login(JaasLoginCoordinator.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeModule(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at
org.apache.geronimo.jetty.JAASJettyRealm.authenticate(JAASJettyRealm.java:94)
at
org.mortbay.jetty.servlet.FormAuthenticator$FormCredential.authenticate(FormAuthenticator.java:305)
at
org.mortbay.jetty.servlet.FormAuthenticator.authenticate(FormAuthenticator.java:148)
at
org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.obtainUser(SecurityContextBeforeAfter.java:282)
at
org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.checkSecurityConstraints(SecurityContextBeforeAfter.java:191)
at
org.apache.geronimo.jetty.JettyWebAppContext.checkSecurityConstraints(JettyWebAppContext.java:585)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:432)
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
RE: Regarding feedback on OpenWire C++ client
Hi Nathan,
1) Use of smart pointers.
Though the user interface would be cleaner without smart pointers
they
serves a purpose even when the passed in object is not owned by the
client.
As soon as an object is shared between two classes you have the
problem when the object should be deleted - this problem is
eliminated
when using SP's, the object is deleted when both object releases its
reference to it.
I'm not sure I agree. For user-generated objects, it should be up to
the user to
add and remove references to them across the openwire library (such as
references
to IMessageListeners). When the user passes in a reference to one of
his objects,
he's not expecting to give any amount of lifetime control to the
openwire code.
In fact, the user object may not even have been created on the heap,
it may be a
local variable that was added just for the scope of a function. In
this case,
when the openwire library decides to delete it, the application blows
up! We
have to make a separation of what is and what is not under our
library's control.
We can't assume a structure of the client code, this forces the client
into a
particular way of programming and causes our client to become a burden
to the
developer and will turn them off to using ActiveMQ.
Regarding objects that the user provides, we still get benefits by using
smart pointers for them. It is not always the creator that is
responsible of deletion. Especially in a threaded application it can be
important to not end-up with ghost pointers. A thread in our client
library that holds a pointer to a listener, must be able to rely on that
the instance is still alive as long as it holds the SP to it. If the
user would provide an ordinary pointer, the user must never delete it as
long as there might be threads in our library using it. What about
static objects that should last forever in the client's lifetime then?
Still, we want to be able to take down the client in a controlled way.
Doing that without smart pointers, may create a lot of problems in our
experience.
The burden for the user would only lie in the classes that implement
our interfaces. If our API requires a pIMessageListener, the user must
hold his message listener using a pMyMessageListener allocated with
new MyMessageLister (...);. The user does not have to let this affect
his design. If the user wants, this instance can lie as a member within
another class that is neither derived from our interface nor maintained
as a smart pointer.
SP's and Strings: Semi-agreed :) The setters should all have const
char*
but we could change the getters to std:string (without SP), then it
is
up to the user to either use it as a std:string or a const char*.
I think symmetry is a good thing. We should pick one way or the other
...
either both the getter and setter take const char* or they both take
strings.
Also, when passing strings around, they should be passed as const
std::string ...
this way you don't have to copy the entire string, you just pass a
constant reference
to it. This will save a lot of processing when dealing with large
text messages, for
example.
The options we have regarding passing and holding strings are the
following:
Class Xxx {
pstring name;
public:
void setName (pstring name) {
this-name = name;
}
pstring getName () {
return this-name;
}
pstring createName() {
return new string (name: + *name);
}
};
In the above example, strings are never copied, just the ptr value. The
downside is that the caller needs to pass their strings as pstring.
This version adds the least overhead.
---
Class Xxx {
string name;
void setName (const string name) {
this-name = name;
}
const string getName () {
return this-name;
}
string createName() {
return string (name: + name);
}
};
In this example the string is always copied in the setters but not in
getters.
---
Class Xxx {
const char* name;
void setName (const char* name) {
this-name = name;
}
const char* getName () {
return this-name;
}
const char* () {
const char* val = new char[256];
strcpy (val, name: );
strcat (val, name);
return val;
}
};
This example is unacceptable since ownership is undefined.
We are open to use any of the first two examples.
Regards,
David Mats
javadoc issue
Hi, I am trying to build javadocs for Geronimo 1.0 code. In general it works fine except for several modules. For example, /modules/kernel contains two set of packages: org.apache.geronimo.kernel.* org.apache.geronimo.gbean.* But I was unable to build javadocs for the last one (org.apache.geronimo.gbean.*). Neither maven javadoc:generate from the /modules/kernel nor maven javadoc from the root src folder works. Javadoc is generated for org.apache.geronimo.kernel.* only. And I didn't find any mention of specific package names in nearby xmls. Did I do something wrong? Thanks! -- Alexei Zakharov, Intel Middleware Product Division
Re: New Feature: Configuration Import/Export
2,3,4 This definitely is the direction I see the tooling support going. We are discussing changes in the WTP Server Tools Framework to allow adopters to extend and provide similar functionality for their servers/runtimes. So these are good usage scenarios I can bring up during my discussions with them. - sachin On Mar 24, 2006, at 9:44 PM, Matt Hogstrom wrote: Aaron, I'll set this up later and give it a spin. I think everyone has been considering how to get to the pluggable server so I'll throw in my 2c about what I think would be useful from a user perspective. I don't know enough about the internals of G to know how to implement it though. AppServers that I'm aware of all operate under the paradigm of installing the AppServer and then iteratively defining resources (DataSources, JMS Queues, etc.) and then installing and maintainging the applications that run in the containers. Of course they are all monolithic monsters that have everything in them that most people don't want or need. I think Little-G and now the work your doing are the right direction and are a new paradigm for the industry. Here are tyhe scenarios that I think make sense as being useful. 1. User downloads a full Geronimo instance and does initial customization using the installer. Pretty much like the paradigm described above. 2. User downloads a bootstrap agent (much like Cygwin) and then chooses either the pacakges they want (specific OSS projects) or the features they want (JMS, Servlet 2.4, EJB 1.1, Spring, etc.) The downloaded agent would resolve the required dependencies and suck down the appropriate parts and configure the runtime. 3. Similar paradigm to above but rather than running a single server instance they would specify a target location to export a server image that would be bootable. The instance they operate from is an AppServer factory and not an AppServer instance. The interfaces would include a GUI (nice user interface, dynamic resolution of dependencies, etc.) as well as a command line utility that could build the instances required for a specific set of applications. 4. A variation on the above would also install the application artifacts and create disposable runtimes. Users could then take these images and distribute them in a cluster and they would be fully functional containers but are designed to be disposed of after use. The paradigm of defining and iterating a server instance doesn't exist in this mode. The disposable instances would be able to federate into a managable cluster from an operations perspective but would be limited to starting and stopping the servers and pulling runtime statistics. Anyway, personally I'm interested in options 3 and 4. I think its a fresh approach to managed runtimes and provides all the functionality of J2EE and other programming models without much of the fuss. The term I use fo rthe above is Geronimo MTO (Made to Order). Kind of like Burger King where you can have it your way. I'd appreciate comments on the above. Matt Aaron Mulder wrote: I've just added a new feature to the console whereby it can export an installed configuration to a CAR file, and also install previously uninstalled configurations (CAR files and dependency JAR files) from a Maven repository (though at present, it depends on a properties file being in the repository the provide some metadata on the available CARs). It also still doesn't have any reasonable feedback during the download process. Anyway, I'm not really looking at this as a final definition of the feature, more a look at what we can do so we can talk about the best way to do it. (For example, we've talked about how it would be nice to have command-line tools to do this, and while some of the code could be extracted, we'd potentially need a separate file upload solution, if we can't reuse the remote-deploy web app. Also, it can only install from a Maven repo [vs a direct file upload] so it can fetch needed dependencies. Also, it doesn't take advantage of the soon-to-be-on-iBiblio Maven repository manager.) As a conversation starter, it would be nice to distribute Geronimo without any sample applications to make it a little leaner and faster to start -- just have the screen in the console that lets you download and install any of them that you want. I also think it would be nice to distribute without Directory and some of the other add-ons, and provide the ability to download and install those, ServiceMix, Quartz, and other packages we know of integration for. If you want to take a look at this, there's an Import/Export entry in the application part of the console navigation bar (in HEAD). You need to set up some Maven repo to point it to (though for a REAL quick start you can just use a file URL like file:///home/ammulder/.maven/repository). And then you need a file in the root of the Maven repo
[jira] Created: (GERONIMO-1783) Welcome application i18n
Welcome application i18n Key: GERONIMO-1783 URL: http://issues.apache.org/jira/browse/GERONIMO-1783 Project: Geronimo Type: New Feature Reporter: Yeray Cabrera Santana Priority: Minor Patch for Welcome app includes i18n and Spanish translation. This patch depends on taglibs-i18n-1.0.jar which is not available on any maven repo. -- 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] Created: (GERONIMO-1784) SQL Login Modules logs null instead of the driver name
SQL Login Modules logs null instead of the driver name Key: GERONIMO-1784 URL: http://issues.apache.org/jira/browse/GERONIMO-1784 Project: Geronimo Type: Bug Components: security Versions: 1.0, 1.1, 1.2 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 1.1, 1.2 SQLLoginModule.java has the following line: throw new IllegalArgumentException(Driver class + driver + is not available. Perhaps you need to add it as a dependency in your deployment plan?) Change to throw new IllegalArgumentException(Driver class + options.get(DRIVER)+ is not available. Perhaps you need to add it as a dependency in your deployment plan?); -- 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
1.1 Release is gearing up...let's start stting the release goals
All, Dain and David have mostly completed their work in branches/1.1. Given that the easy part of the change has been done its time to start thinking about getting 1.1 out the door. The theme for 1.1 I think is appropriate is bug fixes, performance improvements and new features. Here is the order I'd like to proceed with to get 1.1 released: 1. Get the 1.1 release stabilized and freeze changes temporarily. 2. Run the TCK and confirm that what we have passes CTS. 3. Upgrade a limited set of function into 1.1 that is fiarly atomic. 4. Complete a final CTS run and then release 1.1 to the world. As far as the upgrades I expect that there is a lot of function people would like to drop in. Based on what I've seen on the list in terms of discussion here is my initial list. I think a 1.1 release with just the configId changes isn't really that dramatic from a user perspective so I think we need to add some additional content. * Upgrade TranQL and TranQL Connector to 1.3 and 1.2 respectively. I've added a statement cache that gives about a 30% performance boost on JDBC primitives in DayTrader. I think this is a significant improvement over 1.0 and is fairly limited in its scope. * Upgrade ActiveMQ to Version 4. I don't know all the changes so we need Hiram's input here but I think some of the improvements included improved configurability. * Upgrade the Jetty Version to address the security problem we noted in 1.0. * I'll compile a list of outstanding JIRA's for 1.0 and give a first triage on them today. * Tech preview of the installer. Erik, I think that it is ready to go, is this correct? Please respond with your input in terms of what should be included. Please consider that we have only a week or so to get them incorporated before we start the final TCK run. Personally I'd like to shoot for a 1.2 by JavaOne (or at least June if we can't make JavaOne) with some improvements targetted at the schizophrenic server :), ahem, flexible server.) It would be nice to have something to showcase at ApacheCon in June as well as the TSS Europe. Let the creative juices flow. Matt
[jira] Updated: (GERONIMO-1783) Welcome application i18n
[ http://issues.apache.org/jira/browse/GERONIMO-1783?page=all ] Yeray Cabrera Santana updated GERONIMO-1783: Attachment: patch.txt Welcome application i18n Key: GERONIMO-1783 URL: http://issues.apache.org/jira/browse/GERONIMO-1783 Project: Geronimo Type: New Feature Reporter: Yeray Cabrera Santana Priority: Minor Attachments: patch.txt Patch for Welcome app includes i18n and Spanish translation. This patch depends on taglibs-i18n-1.0.jar which is not available on any maven repo. -- 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: Which version of AMQ for geronimo 1.1?
Indeed. On 3/28/06, James Strachan [EMAIL PROTECTED] wrote: Sounds reasonable to me; particulary as ActiveMQ shouldn't really chance a whole lot from here on in in the core broker/connector area; whereas the kernel might change a bit more between 1.0-1.1-1.2-2.x etc James On 3/27/06, Hiram Chirino [EMAIL PROTECTED] wrote: I've been thinking that it may be best to move the ActiveMQ bean modules into the Geronimo source tree. ActiveMQ actually does not ship the gbean modules in it's binary distro, so I think it would make sense to have them actually be maintained inside Geronimo. The upside to this is if Geronimo wants to make kernel level changes it would be easier to apply them to to all the gbeans inside it's source tree. Any thoughts or ideas? On 3/27/06, Donald Woods [EMAIL PROTECTED] wrote: We also have the following JIRA issues opened that need changes in ActiveMQ to fix - G1451 - A new TCP listener for ActiveMQ is not persisting across server starups G1752 - Changing activeMQ port via console doesn't stick -Donald David Jencks wrote: Geronimo 1.1 needs some changes in the activemq gbeans in order for activemq to be able to start and be managed by the console. Which version(s) should I make the modifications in? Should I make an AMQ branch for this? The problems I've identified so far are: - The management helper gbean needs extensive modifications to use AbstractNames rather than ObjectNames. - The JDBCPersistenceAdapterGBean uses an AMQ interface in its reference to dataSource: this no longer works as we now check that a target gbean declares the interface you ask for in a reference. Thanks david jencks -- Regards, Hiram -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram
[jira] Assigned: (GERONIMO-1553) Provide commonj Timer and Work Manager.
[ http://issues.apache.org/jira/browse/GERONIMO-1553?page=all ] Kevan Miller reassigned GERONIMO-1553: -- Assign To: Kevan Miller Provide commonj Timer and Work Manager. --- Key: GERONIMO-1553 URL: http://issues.apache.org/jira/browse/GERONIMO-1553 Project: Geronimo Type: New Feature Components: general Versions: Wish List Environment: na Reporter: Seth White Assignee: Kevan Miller Attachments: commonj.jar, commonj_spec.jar, commonj_timer.jar It would be nice if Geronimo provided an implementation of the Timer and Work Manager APIs specified by commonj. More information on these features can be found here: http://dev2dev.bea.com/wlplatform/commonj/twm.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Which version of AMQ for geronimo 1.1?
Ok, So I was chatting with David Jencks on IRC yesterday, and G 1.1 will stick with the AMQ 3.x branch for now since there seems to be a big push to get G 1.1 out the door and introducing AMQ 4.x could add more delays. But due to a kernel change in 1.1, David is going to update the gbean integration in AMQ 3.x and will will be cutting and using a ActiveMQ 3.2.4. I've finished porting the 1.2 (trunk) branch to ActiveMQ 4.x. OpenEJB still has a ActiveMQ 3.2.1 dependency due to WADI. This is causing the finally assembly to include both versions :( Hey Jules, can WADI/ActiveCluster run with 4.x yet? Please let me know if this broke anything. Regards, Hiram On 3/26/06, Hiram Chirino [EMAIL PROTECTED] wrote: Wow.. I'm a bit confused with all the version stuff then... I've been working off trunk which I assumed was 1.1. I'll attach a patch of what I have so far against trunk. You'll see that I've had to update a bunch of project.xml files in a bunch of modules. So I think we need to branch the whole trunk. If you want, go ahead and create the branch and I'll apply my patch. Also seem the console was providing some DLQ management features. But the interfaces into this stuff in AMQ 4.x has changed substantially. I think we will need to disable that portlet until it can be properly ported. On 3/26/06, David Jencks [EMAIL PROTECTED] wrote: On Mar 26, 2006, at 11:29 AM, Hiram Chirino wrote: Hi David, I've started to update my geronimo 1.1 working copy to use amq 4. Are you sure you mean g 1.1? That is the still broken branch only Dain and I have been working on. g trunk is 1.2 now. If your interested in helping port it over, then yeah I think a branch would be a good idea. What should the branch name be? Well, we called the g. branch configid for a while, then changed it to 1.1 So I think either G_1.1 or configId would be reasonable. We might only need to branch the gbeans rather than all of AMQ, what do you think? thanks david jencks Regards, Hiram On 3/26/06, David Jencks [EMAIL PROTECTED] wrote: Geronimo 1.1 needs some changes in the activemq gbeans in order for activemq to be able to start and be managed by the console. Which version(s) should I make the modifications in? Should I make an AMQ branch for this? The problems I've identified so far are: - The management helper gbean needs extensive modifications to use AbstractNames rather than ObjectNames. - The JDBCPersistenceAdapterGBean uses an AMQ interface in its reference to dataSource: this no longer works as we now check that a target gbean declares the interface you ask for in a reference. Thanks david jencks -- Regards, Hiram -- Regards, Hiram -- Regards, Hiram
Re: 1.1 Release is gearing up...let's start stting the release goals
On 3/28/06, Matt Hogstrom [EMAIL PROTECTED] wrote: [snip] * Upgrade ActiveMQ to Version 4. I don't know all the changes so we need Hiram's input here but I think some of the improvements included improved configurability. Hey I just sent out a related note, but the short of it is since 4.x has not gone under extensive TCK testing with G before, I think it's a bit of risk to switch it out if there is a one week deadline. But I've already updated to 4.x in the 1.2 branch so we can start TCK testing 4.x now for the JavaOne target. Matt -- Regards, Hiram
Re: 1.1 Release is gearing up...let's start stting the release goals
There are a few chunks of code in trunk that probably need to be moved over, like the local configuration's (config.xml) ability to remove attributes/empty values, etc. Jeff Matt Hogstrom wrote: All, Dain and David have mostly completed their work in branches/1.1. Given that the easy part of the change has been done its time to start thinking about getting 1.1 out the door. The theme for 1.1 I think is appropriate is bug fixes, performance improvements and new features. Here is the order I'd like to proceed with to get 1.1 released: 1. Get the 1.1 release stabilized and freeze changes temporarily. 2. Run the TCK and confirm that what we have passes CTS. 3. Upgrade a limited set of function into 1.1 that is fiarly atomic. 4. Complete a final CTS run and then release 1.1 to the world. As far as the upgrades I expect that there is a lot of function people would like to drop in. Based on what I've seen on the list in terms of discussion here is my initial list. I think a 1.1 release with just the configId changes isn't really that dramatic from a user perspective so I think we need to add some additional content. * Upgrade TranQL and TranQL Connector to 1.3 and 1.2 respectively. I've added a statement cache that gives about a 30% performance boost on JDBC primitives in DayTrader. I think this is a significant improvement over 1.0 and is fairly limited in its scope. * Upgrade ActiveMQ to Version 4. I don't know all the changes so we need Hiram's input here but I think some of the improvements included improved configurability. * Upgrade the Jetty Version to address the security problem we noted in 1.0. * I'll compile a list of outstanding JIRA's for 1.0 and give a first triage on them today. * Tech preview of the installer. Erik, I think that it is ready to go, is this correct? Please respond with your input in terms of what should be included. Please consider that we have only a week or so to get them incorporated before we start the final TCK run. Personally I'd like to shoot for a 1.2 by JavaOne (or at least June if we can't make JavaOne) with some improvements targetted at the schizophrenic server :), ahem, flexible server.) It would be nice to have something to showcase at ApacheCon in June as well as the TSS Europe. Let the creative juices flow. Matt
Re: m2: geronimo-packaging-plugin
David,
Thanks! more comments inline..
--- David Jencks [EMAIL PROTECTED] wrote:
On Mar 21, 2006, at 7:13 AM, anita kulshreshtha
wrote:
David J,
This is one of goals from the packaging plugin.
I
need some insight into this :
goal name=car:prepare-plan description=Add
dependencies to a plan and process with velocity
car:dependencies artifacts=${pom.artifacts}
targetDir=${geronimo.packaging.buildDir}
sourceDir=${geronimo.packaging.srcDir}
planFile=${geronimo.packaging.planFile}
targetFile=${geronimo.packaging.buildFile}
context=${context}/
/goal
Is this still needed?
In principle, yes. It may be necessary to hard-code
the dependencies/
imports until the transitive dependencies of all
modules are further
stabilized.
IIUC, you are saying that when all the transitive
dependencies are sorted out, maven would give us the
correct set of artifacts for constructing the
classloader. I think that the packaging-plugin will
always be needed to map geronimo concepts, e.g. import
and include to maven dependencies. I am using
geronimo-gbean-deployer and j2ee-system configs as an
example to figure out what needs to be done. Is there
a better approach?
I agree with your earlier comments
http://issues.apache.org/jira/browse/GERONIMO-1677#action_12370672
I need to think how all this ties together. Is
there any work being done on the DAGclassloader?
This is likely to have a problem similar to the
dependency plugin,
but I haven't thought through whether or not it
actually does :-) I
would start by including all dependencies and
sorting them into
imports and dependencies based on their type.
Since none of the configs have geronimo.include
property. I might be able to get away by using
type=car for geronimo.import and use scope(provided?)
somehow to get the right dependencies. But eventually
we will have to deal with includes.
If
this gets too far
from what the m1 plugin generates we could check in
the dependencies/
imports from the m1 output and revisit this when we
merge 1.1 into
trunk.
If there is an urgency to move to m2, we could
check in all the things
dependencies/imports/geronimo-service.xml. I would
like to know more about the work being done in 1.1 and
its availability.
Thnaks
Anita
thanks
david jencks
Thanks
Anita
__
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
Problems building on windows
I've been encountering a number of problems building on Windows which seem to be steadily getting worse and I was wondering if anybody else is experiencing this (and hopefully has some work-arounds). - Out of Memory Errors. These seem to be related to two different things: 1) Long file names. If I remember correctly Windows has issues if the file names exceed 256 bytes. I've been working with multiple levels of geronimo concurrently and so have had to name the root something other than simply geronimo. It seems like if I start to get longer than 12 characters or so I begin to hit these problems. I think we may be getting into trouble here with the depth of our packages and embedded classes. 2) Extra garbage hanging around in %temp% from previous builds. The geronimo build leaves a lot of trash in %temp% and when that seems to cause problems with out of memory errors and subsequent builds. - File IO errors when running the CRLF plugin. These may be related to the %temp% storage but I seem to get them at times even when I've just cleaned out my %temp%. Running back to back I get different results. Thanks for the help, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Problems building on windows
Joe, Don't worry, all those problems are fixed in Windows Vista. Thanks, Aaron :) On 3/28/06, Joe Bohn [EMAIL PROTECTED] wrote: I've been encountering a number of problems building on Windows which seem to be steadily getting worse and I was wondering if anybody else is experiencing this (and hopefully has some work-arounds). - Out of Memory Errors. These seem to be related to two different things: 1) Long file names. If I remember correctly Windows has issues if the file names exceed 256 bytes. I've been working with multiple levels of geronimo concurrently and so have had to name the root something other than simply geronimo. It seems like if I start to get longer than 12 characters or so I begin to hit these problems. I think we may be getting into trouble here with the depth of our packages and embedded classes. 2) Extra garbage hanging around in %temp% from previous builds. The geronimo build leaves a lot of trash in %temp% and when that seems to cause problems with out of memory errors and subsequent builds. - File IO errors when running the CRLF plugin. These may be related to the %temp% storage but I seem to get them at times even when I've just cleaned out my %temp%. Running back to back I get different results. Thanks for the help, Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
[jira] Commented: (AMQ-660) Add support for MaxDB
[ https://issues.apache.org/activemq/browse/AMQ-660?page=comments#action_35921 ] Hiram Chirino commented on AMQ-660: --- Just added initial support for MaxDB. Requested original poster to submit logs to try to resolve the Old message cleanup failed due to: com.sap.dbtech.jdbc.exceptions.DatabaseException: [-9404]: System error: AK System error: VAK724 1 error. Add support for MaxDB - Key: AMQ-660 URL: https://issues.apache.org/activemq/browse/AMQ-660 Project: ActiveMQ Type: New Feature Components: Message Store Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.0 RC 2 Originaly reported on the user mailing list: http://www.nabble.com/Adding-support-for-MaxDB-in-ActiveMQ-JDBC-persistence-layer-t1334466.html#a3572564 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1785) Application migration to Maven 2: magicGball
Application migration to Maven 2: magicGball Key: GERONIMO-1785 URL: http://issues.apache.org/jira/browse/GERONIMO-1785 Project: Geronimo Type: Sub-task Reporter: Prasad Kashyap Assigned to: Prasad Kashyap -- 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-1785) Application migration to Maven 2: magicGball
[ http://issues.apache.org/jira/browse/GERONIMO-1785?page=all ] Prasad Kashyap updated GERONIMO-1785: - Attachment: magicGball.patch Apply patch from geronimo/applications dir. Creates sub projects for ejb, client and web. Then builds the ear. Test of this app not yet complete. Need to know the final packaging, location of the assembly (distribution binary). Application migration to Maven 2: magicGball Key: GERONIMO-1785 URL: http://issues.apache.org/jira/browse/GERONIMO-1785 Project: Geronimo Type: Sub-task Reporter: Prasad Kashyap Assignee: Prasad Kashyap Attachments: magicGball.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-1092) Create a Maven2 build for the Daytrader sample app
[ http://issues.apache.org/jira/browse/GERONIMO-1092?page=all ] Matt Hogstrom closed GERONIMO-1092: --- Fix Version: 1.1 (was: 1.x) Resolution: Fixed Applied patches and staged DayTrader to geronimo/daytrader from geronimo/trunk/applications/daytrader. Create a Maven2 build for the Daytrader sample app -- Key: GERONIMO-1092 URL: http://issues.apache.org/jira/browse/GERONIMO-1092 Project: Geronimo Type: Task Components: sample apps Versions: 1.0-M5 Reporter: Vincent Massol Assignee: Matt Hogstrom Fix For: 1.1 Attachments: daytrader-vmassol1-matches-326852.zip, daytrader-vmassol2-new-directory-structure-with-m2-poms.zip, daytrader-vmassol3-xdocletification-ejb-lester.zip -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-927) Provide a statement cache for TranQL for JDBCs drivers that don't inherintly provide this functionality.
[ http://issues.apache.org/jira/browse/GERONIMO-927?page=all ] Matt Hogstrom updated GERONIMO-927: --- Fix Version: 1.1 (was: 1.2) Updated TranQL connector and vendors to add stmt caching capability. Currently testing and refining. Targetting for inclusion in Geronimo 1.1. Provide a statement cache for TranQL for JDBCs drivers that don't inherintly provide this functionality. Key: GERONIMO-927 URL: http://issues.apache.org/jira/browse/GERONIMO-927 Project: Geronimo Type: New Feature Versions: 1.0-M4 Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.1 Not all JDBC providers currently provide a statement cache on a per connection basis. This can be a very expensive operation that impacts performance of not only Geronimo but of the database being used. -- 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: [jira] Created: (GERONIMO-1775) Internationalization of the Admin Console
Hi, I think this is an important item and appreciate you taking the initiative on it. If you're interested in breaking this up into subtasks then I'm willing to help out. Unfortunately I don't know a second language well enough to help with translation but I can help code :-) As for the specifics, I think it would make sense to use a similar approach that Apache Jetspeed2 uses for its admin console. You can inspect the src here: https://svn.apache.org/repos/asf/portals/jetspeed-2/trunk/applications/j2-admin/ Specfically: - use org.apache.geronimo.console.xyz.resources for package names - use PortletNameResources.properties for the file names - use PortletName.[label | msg | error].key for the resource names (this seems to be a mixed bag, though) Also instead of the standalone i18n library I think it would be more strategic to use the JCP standardized tag library v1.1 (which I believe it supercedes). What do you think? Best wishes, Paul On 3/27/06, Sean McCarthy [EMAIL PROTECTED] wrote: Hi, We would like to start working on the translation (Yeray and me). But before that, we'd like to hear about the way we should do it. We have internationalized and translated the welcome page into Spanish using the jakarta taglibs-i18n with resource bundles. If there's not problem about using these libs, they have to be added to one repo (or point us to the right one) because we haven't found them on any maven repository (we've checked the repos available in the project.properties). Also we would like to know which is the preferred way to bundle the resources: package name, resource bundle name, specific naming for the resources, etc. We can attach the internationalized version of the welcome webapp to the Jira issue to have a look at the way we are doing it. Regards, Sean Yeray Cabrera Santana (JIRA) wrote: Internationalization of the Admin Console - Key: GERONIMO-1775 URL: http://issues.apache.org/jira/browse/GERONIMO-1775 Project: Geronimo Type: Improvement Components: console Reporter: Yeray Cabrera Santana Priority: Minor Provide the internationalization of the administration console so it can be translated to different languages. This is a feature I would like to contribute with. -- Sean C. McCarthy Integra Soluciones Avanzadas, S.L. Tlf: +34928465203 C/ Juan Domínguez Pérez 28, Urb El Sebadal Las Palmas de Gran Canaria (35008) SPAIN
Re: 1.1 Release is gearing up...let's start stting the release goals
Matt, I need the rest of the week to get the installer ready. I have at least two more patches to provide before I'm finished. I should have them done by the end of the week. regards, erik On Tue, 2006-03-28 at 11:04 -0500, Matt Hogstrom wrote: All, Dain and David have mostly completed their work in branches/1.1. Given that the easy part of the change has been done its time to start thinking about getting 1.1 out the door. The theme for 1.1 I think is appropriate is bug fixes, performance improvements and new features. Here is the order I'd like to proceed with to get 1.1 released: 1. Get the 1.1 release stabilized and freeze changes temporarily. 2. Run the TCK and confirm that what we have passes CTS. 3. Upgrade a limited set of function into 1.1 that is fiarly atomic. 4. Complete a final CTS run and then release 1.1 to the world. As far as the upgrades I expect that there is a lot of function people would like to drop in. Based on what I've seen on the list in terms of discussion here is my initial list. I think a 1.1 release with just the configId changes isn't really that dramatic from a user perspective so I think we need to add some additional content. * Upgrade TranQL and TranQL Connector to 1.3 and 1.2 respectively. I've added a statement cache that gives about a 30% performance boost on JDBC primitives in DayTrader. I think this is a significant improvement over 1.0 and is fairly limited in its scope. * Upgrade ActiveMQ to Version 4. I don't know all the changes so we need Hiram's input here but I think some of the improvements included improved configurability. * Upgrade the Jetty Version to address the security problem we noted in 1.0. * I'll compile a list of outstanding JIRA's for 1.0 and give a first triage on them today. * Tech preview of the installer. Erik, I think that it is ready to go, is this correct? Please respond with your input in terms of what should be included. Please consider that we have only a week or so to get them incorporated before we start the final TCK run. Personally I'd like to shoot for a 1.2 by JavaOne (or at least June if we can't make JavaOne) with some improvements targetted at the schizophrenic server :), ahem, flexible server.) It would be nice to have something to showcase at ApacheCon in June as well as the TSS Europe. Let the creative juices flow. Matt
[jira] Created: (GERONIMO-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
JMS Listeners for protocols activeio, peer and openwire fail to start - Key: GERONIMO-1786 URL: http://issues.apache.org/jira/browse/GERONIMO-1786 Project: Geronimo Type: Bug Components: ActiveMQ, console Versions: 1.0, 1.1, 1.2 Environment: Geronimo 1.0.0 Reporter: Donald Woods Even though addition of JMS Listeners for activeio, peer and openwire protocols is successful, the listeners fail to start with the following exceptions. activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found openwire --- javax.jms.JMSException: Could not load protocol: openwire. Reason: java.lang.ClassNotFoundException: org.activemq.transport.openwire.OpenWireTransportServerChannelFactory peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: java.lang.ClassNotFoundException: org.activemq.transport.peer.PeerTransportServerChannelFactory Stack trace of the same. 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found 194: at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo rtServerChannelFactory.java:60) 195: at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact ory.java:49) 196: at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) 197: at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) 198: at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) 199: at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) 200: at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) 201: at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled Code)) 202: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) 203: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) 204: at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) 205: at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) 206: at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) 207: at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java :365) 208: at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) 209: at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive(generated) 210: at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) 211: at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 216: at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) 217: at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) 218: at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) 219: at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) 220: at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) 221: at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) 222: at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) 223: at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) 224: at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.j ava:82) 225: at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) 226: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) 227: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) 228: at
[jira] Commented: (GERONIMO-1553) Provide commonj Timer and Work Manager.
[ http://issues.apache.org/jira/browse/GERONIMO-1553?page=comments#action_12372180 ] Kevan Miller commented on GERONIMO-1553: Seth, Thanks! Apologies for the long delay. We got a bit distracted and this fell off the to-do list... I fixed a few minor bugs, improved suspend processing, and added basic closed/stopped TimerListener support. Adding LICENSE.txt Adding NOTICE.txt Adding pom.xml Adding project.xml Adding src Adding src/java Adding src/java/org Adding src/java/org/apache Adding src/java/org/apache/geronimo Adding src/java/org/apache/geronimo/commonj Adding src/java/org/apache/geronimo/commonj/timers Adding src/java/org/apache/geronimo/commonj/timers/ScheduledRunnable.java Adding src/java/org/apache/geronimo/commonj/timers/ScheduledTimerExecutor.java Adding src/java/org/apache/geronimo/commonj/timers/State.java Adding src/java/org/apache/geronimo/commonj/timers/TimerImpl.java Adding src/java/org/apache/geronimo/commonj/timers/TimerManagerImpl.java Adding src/java/org/apache/geronimo/commonj/timers/WorkRunnable.java Adding src/test Adding src/test/org Adding src/test/org/apache Adding src/test/org/apache/geronimo Adding src/test/org/apache/geronimo/commonj Adding src/test/org/apache/geronimo/commonj/timers Adding src/test/org/apache/geronimo/commonj/timers/TimerManagerTest.java Transmitting file data ... Committed revision 389653. Plenty of work still to do... Provide commonj Timer and Work Manager. --- Key: GERONIMO-1553 URL: http://issues.apache.org/jira/browse/GERONIMO-1553 Project: Geronimo Type: New Feature Components: general Versions: Wish List Environment: na Reporter: Seth White Assignee: Kevan Miller Attachments: commonj.jar, commonj_spec.jar, commonj_timer.jar It would be nice if Geronimo provided an implementation of the Timer and Work Manager APIs specified by commonj. More information on these features can be found here: http://dev2dev.bea.com/wlplatform/commonj/twm.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1787) Possible to have a configuration partially installed that is not possible to undeploy
Possible to have a configuration partially installed that is not possible to undeploy - Key: GERONIMO-1787 URL: http://issues.apache.org/jira/browse/GERONIMO-1787 Project: Geronimo Type: Bug Components: deployment, kernel Versions: 1.0 Environment: Windows XP 1.0 branch rev 379335. Reporter: John Sisson Priority: Minor Fix For: 1.1 When a configuration is being deployed, it causes GBeans to be serialized to the config store. During serialization, static initializers in EJBs are executed. If the static initializers in the EJBs throw an exception it appears to leave the config in the config store in a partially deployed state that cannot be undeployed. The workaround to undeploy it is to edit the geronimo\config-store\index.properties file and to delete the numbered directory for the configuration under the geronimo\config-store directory. Here is an example of a static initializer of an EJB being executed during deployment. (More info below stack trace). System Thread [RMI TCP Connection(5)-172.21.35.100] (Suspended (exception java.lang.ClassCastException)) org.apache.xerces.parsers.DOMParser.init(org.apache.xerces.util.SymbolTable, org.apache.xerces.xni.grammars.XMLGrammarPool) line: not available org.apache.xerces.parsers.DOMParser.init() line: not available SNIP com.acme.myapp.ejb.MyBean.clinit() line: not available java.io.ObjectStreamClass.hasStaticInitializer(java.lang.Class) line: not available [native method] java.io.ObjectStreamClass.computeDefaultSUID(java.lang.Class) line: 1557 java.io.ObjectStreamClass.access$100(java.lang.Class) line: 47 java.io.ObjectStreamClass$1.run() line: 173 java.security.AccessController.doPrivileged(java.security.PrivilegedAction) line: not available [native method] java.io.ObjectStreamClass.getSerialVersionUID() line: 170 java.io.ObjectStreamClass.writeNonProxy(java.io.ObjectOutputStream) line: 557 java.io.ObjectOutputStream.writeClassDescriptor(java.io.ObjectStreamClass) line: 591 java.io.ObjectOutputStream.writeNonProxyDesc(java.io.ObjectStreamClass, boolean) line: 1142 java.io.ObjectOutputStream.writeClassDesc(java.io.ObjectStreamClass, boolean) line: 1100 java.io.ObjectOutputStream.writeClass(java.lang.Class, boolean) line: 1082 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 996 java.io.ObjectOutputStream.defaultWriteFields(java.lang.Object, java.io.ObjectStreamClass) line: 1332 java.io.ObjectOutputStream.writeSerialData(java.lang.Object, java.io.ObjectStreamClass) line: 1304 java.io.ObjectOutputStream.writeOrdinaryObject(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1247 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1052 java.io.ObjectOutputStream.defaultWriteFields(java.lang.Object, java.io.ObjectStreamClass) line: 1332 java.io.ObjectOutputStream.writeSerialData(java.lang.Object, java.io.ObjectStreamClass) line: 1304 java.io.ObjectOutputStream.writeOrdinaryObject(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1247 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1052 java.io.ObjectOutputStream.defaultWriteFields(java.lang.Object, java.io.ObjectStreamClass) line: 1332 java.io.ObjectOutputStream.writeSerialData(java.lang.Object, java.io.ObjectStreamClass) line: 1304 java.io.ObjectOutputStream.writeOrdinaryObject(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1247 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1052 java.io.ObjectOutputStream.defaultWriteFields(java.lang.Object, java.io.ObjectStreamClass) line: 1332 java.io.ObjectOutputStream.writeSerialData(java.lang.Object, java.io.ObjectStreamClass) line: 1304 java.io.ObjectOutputStream.writeOrdinaryObject(java.lang.Object, java.io.ObjectStreamClass, boolean) line: 1247 java.io.ObjectOutputStream.writeObject0(java.lang.Object, boolean) line: 1052 java.io.ObjectOutputStream.writeObject(java.lang.Object) line: 278 org.apache.geronimo.gbean.GBeanData.writeExternal(java.io.ObjectOutput) line: 137 org.apache.geronimo.kernel.config.Configuration.storeGBeans(java.util.List) line: 614 org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.getConfigurationGBeanData(org.apache.geronimo.kernel.config.ConfigurationData) line: 166 org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(org.apache.geronimo.kernel.config.ConfigurationData, java.io.File) line: 122
[jira] Created: (GERONIMO-1788) Allow for disabling of cookies in web application
Allow for disabling of cookies in web application - Key: GERONIMO-1788 URL: http://issues.apache.org/jira/browse/GERONIMO-1788 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0 Reporter: Jeff Genender Fix For: 1.2 Tomcat's context allows for disabling cookies. Geronimo does not give access to this ability. -- 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] Assigned: (GERONIMO-1788) Allow for disabling of cookies in web application
[ http://issues.apache.org/jira/browse/GERONIMO-1788?page=all ] Jeff Genender reassigned GERONIMO-1788: --- Assign To: Jeff Genender Allow for disabling of cookies in web application - Key: GERONIMO-1788 URL: http://issues.apache.org/jira/browse/GERONIMO-1788 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0 Reporter: Jeff Genender Assignee: Jeff Genender Fix For: 1.2 Tomcat's context allows for disabling cookies. Geronimo does not give access to this ability. -- 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-1788) Allow for disabling of cookies in web application
[ http://issues.apache.org/jira/browse/GERONIMO-1788?page=all ] Jeff Genender closed GERONIMO-1788: --- Resolution: Fixed Added a disable-cookies tag to the tomcat version of the web configuration. This will allow the user/developer to declaritively disable cookies for a web application. Sending modules/tomcat/src/java/org/apache/geronimo/tomcat/GeronimoStandardContext.java Sending modules/tomcat/src/java/org/apache/geronimo/tomcat/TomcatContext.java Sending modules/tomcat/src/java/org/apache/geronimo/tomcat/TomcatWebAppContext.java Sending modules/tomcat-builder/src/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java Sendingmodules/tomcat-builder/src/schema/geronimo-tomcat-1.0.xsd Sendingmodules/tomcat-builder/src/schema/geronimo-tomcat-config-1.0.xsd Transmitting file data .. Committed revision 389664. Allow for disabling of cookies in web application - Key: GERONIMO-1788 URL: http://issues.apache.org/jira/browse/GERONIMO-1788 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0 Reporter: Jeff Genender Assignee: Jeff Genender Fix For: 1.2 Tomcat's context allows for disabling cookies. Geronimo does not give access to this ability. -- 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-396) Transient failure to install configuration on WinXP/JDK1.5
[ http://issues.apache.org/jira/browse/GERONIMO-396?page=all ] John Sisson closed GERONIMO-396: Fix Version: 1.1 (was: 1.x) Resolution: Fixed This problem should be fixed by changes for GERONIMO-1465: http://svn.apache.org/viewcvs?rev=368569view=rev FYI.. I have also found some other issues on windows machines that can cause problems with file handles being open causing IOExceptions: Disable XP's file indexing (which I have done). It looks like this has caused problems for Java elsewhere (see the workaround in this bug).. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5006328 The following utility is good for tracking down processes that have file handles open.. http://www.sysinternals.com/Utilities/ProcessExplorer.html . Use the Find--Find Handle menu option and specify the file name. I had some similar problems ended up tracking it down my incorrectly configured Diskeeper disk defragmenter that had paused defragmentation and held file handles open. Transient failure to install configuration on WinXP/JDK1.5 -- Key: GERONIMO-396 URL: http://issues.apache.org/jira/browse/GERONIMO-396 Project: Geronimo Type: Bug Components: deployment, buildsystem, JVM-compatibility Reporter: Jeremy Boynes Assignee: Jeremy Boynes Fix For: 1.1 During the build, the deployment of the client configuration fails when trying to rename the index.properties file. This works on JDK1.4.2_05 and under 1.5 when run from the command line. [echo] Building client.jar [java] org.apache.geronimo.deployment.DeploymentException: java.io.IOExcepti on: Can not delete file C:\apache\geronimo\trunk\modules\assembly\target\geronim o-1.0-SNAPSHOT\config-store\index.properties [java] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java: 213) [java] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java: 83) [java] at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMet aDataImpl.java:213) [java] at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java :220) [java] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke( DefaultMBeanServerInterceptor.java:815) [java] at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer. java:784) [java] at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:232) [java] at org.apache.geronimo.system.main.CommandLine.init(CommandLin e.java:106) [java] at org.apache.geronimo.system.main.CommandLine.main(CommandLine. java:64) [java] Caused by: java.io.IOException: Can not delete file C:\apache\geronim o\trunk\modules\assembly\target\geronimo-1.0-SNAPSHOT\config-store\index.propert ies [java] at org.apache.geronimo.system.configuration.LocalConfigStore.sav eIndex(LocalConfigStore.java:129) [java] at org.apache.geronimo.system.configuration.LocalConfigStore.ins tall(LocalConfigStore.java:215) [java] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java: 191) [java] ... 8 more -- 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: Problems building on windows
Joe Bohn wrote: I've been encountering a number of problems building on Windows which seem to be steadily getting worse and I was wondering if anybody else is experiencing this (and hopefully has some work-arounds). - Out of Memory Errors. These seem to be related to two different things: 1) Long file names. If I remember correctly Windows has issues if the file names exceed 256 bytes. I've been working with multiple levels of geronimo concurrently and so have had to name the root something other than simply geronimo. It seems like if I start to get longer than 12 characters or so I begin to hit these problems. I think we may be getting into trouble here with the depth of our packages and embedded classes. Yes, it is concerning.. http://mail-archives.apache.org/mod_mbox/geronimo-dev/200601.mbox/[EMAIL PROTECTED] I also have had to shorten my directory path I am building in. The long file name issue should go way when we move to JDK 1.5_06 but a number of other programs on Windows that deal with files also have the issue (e.g. Windows File Explorer, WinZip, Visual SourceSafe) so this issue could bite us with users complaining that other tools they are using can't work with Geronimo's long directory paths. Do we have a JIRA for this issue? 2) Extra garbage hanging around in %temp% from previous builds. The geronimo build leaves a lot of trash in %temp% and when that seems to cause problems with out of memory errors and subsequent builds. See http://issues.apache.org/jira/browse/GERONIMO-777 Are you seeing these problems on trunk, 1.0 or 1.1 branches or all? What JDK are you using? For a long time I have been using the following (from memory I think there was something in maven or one of the libraries it uses that had a leak - not sure if this still exists) SET MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m What command are you using to build? (this could possibly affect what code gets invoked and how much memory is used). Do you have MAVEN_OPTS environment variables set? I will try to reproduce with the same JDK level and commands once you provide the info. - File IO errors when running the CRLF plugin. These may be related to the %temp% storage but I seem to get them at times even when I've just cleaned out my %temp%. Running back to back I get different results. One thing to try is disabling XP's file indexing (which I have done). It looks like this has caused problems for Java elsewhere (see the workaround in this bug).. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5006328 I also found that http://www.sysinternals.com/Utilities/ProcessExplorer.html utility is good for tracking down processes that have file handles open. Use the Find--Find Handle menu option and specify the file name. I had some similar problems for a while and ended up tracking it down my incorrectly configured Diskeeper disk defragmenter that had paused defragmentation and held file handles open. Have you tried with real-time virus checking disabled to check it isn't a virus checker causing issues? What files are you getting the IO errors on? Can you include the error output? It makes me wonder if we need to have some kind of retry logic for file operations if we are possibly competing with file indexers etc so we can run on a Windows box without problems. I noticed some of the Ant tasks have retry logic for some file operations: http://svn.apache.org/viewcvs.cgi/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Mkdir.java?view=markup http://svn.apache.org/viewcvs.cgi/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Delete.java?view=markup Regards, John Thanks for the help, Joe
[jira] Created: (GERONIMO-1789) Exceptions while adding SQL Realm thru Admin Console
Exceptions while adding SQL Realm thru Admin Console - Key: GERONIMO-1789 URL: http://issues.apache.org/jira/browse/GERONIMO-1789 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: WinXP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Fix For: 1.2 Adding SQL Realm using Database pool succeeds. Problem is with one that uses jdbc connection parameters. Even though the jar contains the driver class, the following exception is logged while adding an SQL realm through Admin Console. 468: 16:26:10,728 WARN [SecurityRealmPortlet] Unable to initialize LoginModule 469: java.lang.IllegalArgumentException: Driver class null is not available. Perhaps you need to add it as a dependency in your deployment plan? 470: at org.apache.geronimo.security.realm.providers.SQLLoginModule.initialize(SQLLoginModule.java:134) 471: at org.apache.geronimo.console.util.KernelManagementHelper.testLoginModule(KernelManagementHelper.java:1045) 472: at org.apache.geronimo.console.util.PortletManager.testLoginModule(Portletanager.java:164) 473: at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.actionTestLoginModuleLoad(SecurityRealmP ortlet.java:258) 474: at org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.processAction(SecurityRealmPortlet.java: 177) 475: at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) 476: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) 477: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) 478: at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code)) 479: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) 480: at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) 481: at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) 482: at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) 483: at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) 484: at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) 485: at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) 486: at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) 487: at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) 488: at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.j ava:82) 489: at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) 490: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) 491: at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code)) 492: at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) 493: at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) 494: at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) 495: at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) 496: at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) 497: at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482) 498: at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:273) 499: at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) 500: at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) 501: at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) 502: at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) 503: at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) 504: at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) 505: at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) 506: at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) 507: at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) 508: at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) 509: at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) 510: at java.lang.Thread.run(Thread.java:570) -- 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:
