RE: [jira] Commented: (AMQ-656) Update of AMQ C++ client
Looks great, thanks! :) Regards, Mats -Original Message- From: Nathan Mittler (JIRA) [mailto:[EMAIL PROTECTED] Sent: den 28 april 2006 00:05 To: activemq-dev@geronimo.apache.org Subject: [jira] Commented: (AMQ-656) Update of AMQ C++ client [ https://issues.apache.org/activemq/browse/AMQ-656?page=comments#action_36104 ] Nathan Mittler commented on AMQ-656: Mats David, I've added this patch to svn. Check it out and make sure all is as it should be :) Regards, Nate Update of AMQ C++ client Key: AMQ-656 URL: https://issues.apache.org/activemq/browse/AMQ-656 Project: ActiveMQ Type: Improvement Components: JMS client Reporter: MF Attachments: README.TXT, source_060323.zip, source_060324.zip, source_060404.zip, source_060406.zip, source_060425.zip Attached is a new update of the C++ client, the zip-file contains the full source since the update is a major overhaul. -- 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: Avoid blocking producers
Hi Chris, we are planning on prototyping this for 4.1 and will do this side-by- side to the existing implementation. We should have the first cut implemented in the next couple of months - but any contributions are welcome! cheers, Rob On 27 Apr 2006, at 23:32, Larrieu, Christopher wrote: Rob, In response to JIRA issue https://issues.apache.org/activemq/browse/ AMQ-688#action_36051 you mentioned that you are looking into some major changes for decoupling producers and consumers, as well as implementing the staged feeding of dispatch queues. Much of this coincides with work that we need in order to use ActiveMQ effectively in our organization. If we were to move forward independently without collaborating, we'd end up arriving with wildly divergent results. Can you provide some more details, so that we can plan accordingly? Thanks, Chris
Re: JMS tutorial using ActiveMQ ,Tomcat and Axis
hi, you can go to my web site http://ww.jsports.org In my web site forum(ActiveMQ),I write two article about how to use activemq in servlet. I think,if you can use it in servlet,you will be able to use it anywhere. -- I love Java! I love Sports! I love this Game ! home:http://www.jsports.org blog: http://blog.csdn.net/jsports http://blog.matrix.org.cn/page/jsports
ConsumerInfo command tweak.
FYI for those openwire watchers. I just added a 'noRangeAcks' flag to the ConsumerInfo command. Not really used yet, but I figure it may be useful in the future and I'd rather get these small flags in before 4.0 goes final. The broker may be able to optimize it's processing or provides better QOS if it knows the consumer will not be sending ranged acks. A simple use case is to allow messages to be reordered based on priority while it's sitting in queues post the broker dispatch stage. If the client is doing ranged acks, reordering would not be allowed since the order the client receives the messages must match the order that the broker dispatched them in so that it acks the right messages in the ack range. -- Regards, Hiram
RE: Avoid blocking producers
Great! But what exactly does side-by-side mean? Does this imply that whatever changes you make will be swappable with existing code? Are there any design documents that we can review in order to understand how your improvements will affect our goals and/or meet our needs? Thanks, Chris -Original Message- From: Rob Davies [mailto:[EMAIL PROTECTED] Sent: Friday, April 28, 2006 1:34 AM To: activemq-dev@geronimo.apache.org Subject: Re: Avoid blocking producers Hi Chris, we are planning on prototyping this for 4.1 and will do this side-by- side to the existing implementation. We should have the first cut implemented in the next couple of months - but any contributions are welcome! cheers, Rob On 27 Apr 2006, at 23:32, Larrieu, Christopher wrote: Rob, In response to JIRA issue https://issues.apache.org/activemq/browse/ AMQ-688#action_36051 you mentioned that you are looking into some major changes for decoupling producers and consumers, as well as implementing the staged feeding of dispatch queues. Much of this coincides with work that we need in order to use ActiveMQ effectively in our organization. If we were to move forward independently without collaborating, we'd end up arriving with wildly divergent results. Can you provide some more details, so that we can plan accordingly? Thanks, Chris
[jira] Resolved: (SM-416) Make JbiTask acquire JMX connection with username and password
[ https://issues.apache.org/activemq/browse/SM-416?page=all ] Guillaume Nodet resolved SM-416: Fix Version: 3.0-M2 Resolution: Fixed Assign To: Guillaume Nodet Author: gnodet Date: Fri Apr 28 00:59:43 2006 New Revision: 397794 URL: http://svn.apache.org/viewcvs?rev=397794view=rev Log: SM-416: Make JbiTask acquire JMX connection with username and password Patch provided by William Wong, thx ! Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/management/task/JbiTask.java Make JbiTask acquire JMX connection with username and password -- Key: SM-416 URL: https://issues.apache.org/activemq/browse/SM-416 Project: ServiceMix Type: Wish Components: servicemix-core Reporter: William Wong Assignee: Guillaume Nodet Priority: Minor Fix For: 3.0-M2 Attachments: JbiTask.patch Currently, the username and password attributes for JbiTask is dummy. They have not been used for JMX Connection setup. To fix it, we could modify the JbiTask as the attachment. Reference discussion: http://www.nabble.com/forum/Reply.jtp?post=4116663 -- 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-414) SourceTransformer cant transf orm to DOM with non US ASCI I characters like 'ä' or 'ü'
[ https://issues.apache.org/activemq/browse/SM-414?page=all ]
Guillaume Nodet resolved SM-414:
Fix Version: 3.0-M2
(was: 3.0)
(was: incubation)
Resolution: Fixed
Assign To: Guillaume Nodet
Author: gnodet
Date: Fri Apr 28 01:12:59 2006
New Revision: 397796
URL: http://svn.apache.org/viewcvs?rev=397796view=rev
Log:
SM-414: SourceTransformer cant transform to DOM with non US ASCII characters
Patch provided by Juergen Mayrbaeurl, thx !
Modified:
incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/jaxp/SourceTransformer.java
incubator/servicemix/trunk/servicemix-core/src/test/java/org/apache/servicemix/jbi/jaxp/SourceTransformerTest.java
SourceTransformer cant transform to DOM with non US ASCII characters like 'ä'
or 'ü'
Key: SM-414
URL: https://issues.apache.org/activemq/browse/SM-414
Project: ServiceMix
Type: Bug
Components: servicemix-core
Versions: 3.0-M1, 3.0-M2, 3.0, incubation
Environment: W2K, J2SE 1.4.2, Xerces 2.7.1, default locale of OS with
character set 'windows-1252'
Reporter: Juergen Mayrbaeurl
Assignee: Guillaume Nodet
Priority: Blocker
Fix For: 3.0-M2
Attachments: SampleInMessage.xml, SourceTransformer-sources.zip,
SourceTransformerTest_patch.txt
The class org.apache.servicemix.jbi.jaxp.SourceTransformer, which belongs to
the core classes of ServiceMix and is used very often, has major problems
transforming Source to DOM data structures, when the source contains non
US-ASCII charactes like 'ä' or 'ü'.
The class uses DocumentBuilders (see method 'public DOMSource
toDOMSourceFromStream(StreamSource source) throws
ParserConfigurationException, IOException, SAXException') for the
transformation and uses the method 'public Document parse(InputStream is,
String systemId) throws SAXException, IOException' without explicitly telling
the DocumentBuilder the character encoding it should use. This results in
fatal errors (exceptions) returned by the DocumentBuilder (Xerces 2.7.1),
because it encounters invalid character code sequences (especially with UTF-8
and multi-byte characters like 'ä' or 'ö'). This means that you can't use non
US-ASCII characters in messages, as soon as ServiceMix uses an instance of
the class SourceTransformer to do any transformation to DOM. This is the case
when tracing messages in the DeliveryChannel or evaluating an XPath
expression for e.g. Content based routing.
The solution to this problem is straight forward: Tell the DocumentBuilder
the character encoding it has to use. Looks like:
public DOMSource toDOMSourceFromStream(StreamSource source) throws
ParserConfigurationException, IOException,
SAXException {
DocumentBuilder builder = createDocumentBuilder();
String systemId = source.getSystemId();
Document document = null;
InputStream inputStream = source.getInputStream();
if (inputStream != null) {
InputSource inputsource = new InputSource(inputStream);
inputsource.setSystemId(systemId);
inputsource.setEncoding(defaultCharEncodingName); // -- Very
important
document = builder.parse(inputsource);
}
else {
Reader reader = source.getReader();
if (reader != null) {
document = builder.parse(new InputSource(reader));
}
else {
throw new IOException(No input stream or reader available);
}
}
return new DOMSource(document, systemId);
}
I've attached the original source file of SourceTransformer (3.0 SNAPSHOT,
2006-04-20) and the changed (Unfortunately I can't create a real patch).
Kind regards
Juergen
--
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-415) Add a simple NamespaceContext implementation easily configurable from xbean
[ https://issues.apache.org/activemq/browse/SM-415?page=all ] Guillaume Nodet resolved SM-415: Fix Version: 3.0-M2 Resolution: Fixed Assign To: Guillaume Nodet Author: gnodet Date: Fri Apr 28 01:57:42 2006 New Revision: 397808 URL: http://svn.apache.org/viewcvs?rev=397808view=rev Log: SM-415: Add a simple NamespaceContext implementation easily configurable from xbean Added: incubator/servicemix/trunk/servicemix-eip/src/main/java/org/apache/servicemix/eip/support/NamespaceContextImpl.java incubator/servicemix/trunk/servicemix-eip/src/test/java/org/apache/servicemix/eip/support/ incubator/servicemix/trunk/servicemix-eip/src/test/java/org/apache/servicemix/eip/support/NamespaceContextImplTest.java incubator/servicemix/trunk/servicemix-eip/src/test/resources/org/apache/servicemix/eip/support/ incubator/servicemix/trunk/servicemix-eip/src/test/resources/org/apache/servicemix/eip/support/nscontext.xml Modified: incubator/servicemix/trunk/servicemix-eip/src/test/java/org/apache/servicemix/eip/SpringConfigurationTest.java incubator/servicemix/trunk/servicemix-eip/src/test/resources/org/apache/servicemix/eip/spring.xml Add a simple NamespaceContext implementation easily configurable from xbean --- Key: SM-415 URL: https://issues.apache.org/activemq/browse/SM-415 Project: ServiceMix Type: Improvement Components: servicemix-eip Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.0-M2 This is a real need for xpath based EIP patterns -- 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
Testing the Installation
At http://servicemix.org/Getting+Started; in Testing the Installation I have read that The Window's console window [...] will display something similar to the following log line if ServiceMix is up and running without any problems: [INFO] JBIContainer -- ServiceMix JBI Container http://servicemix.org/ name: defaultJBI running version: null When I start servicemix from installation directory (ex: D:\Program Files\servicemix-2.0.2) the Window's consol display the following message: ServiceMix ESB: 2.0.2 Loading ServiceMix from servicemix.xml on the CLASSPATH 12:05:47,917 INFO [JournalPersistenceAdapter] Opening journal. 12:05:48,017 INFO [JournalPersistenceAdapter] Opened journal: Active Journal: u sing 2 x 20.0 Megs at: ..\var\journal 12:05:48,017 INFO [JournalPersistenceAdapter] Journal Recovery Started. 12:05:48,147 INFO [JournalPersistenceAdapter] Journal Recovered: 0 message(s) i n transactions recovered. Is this correct? Thank's a lot -- View this message in context: http://www.nabble.com/Testing-the-Installation-t1523627.html#a4137672 Sent from the ServiceMix - Dev forum at Nabble.com.
Getting BC from MessageExchange
Can I get the name of an bindind component from the MessageExcheangeImpl ?? I´m extending the SedaFlow class to do some especific logic, but I need to get the componentes the send and receive the message. Is it possible? -- View this message in context: http://www.nabble.com/Getting-BC-from-MessageExchange-t1524872.html#a4141367 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Shutdown Script
On 4/28/06, Philip Dodds [EMAIL PROTECTED] wrote: Anyone had any thought on putting together a remote shutdown script? and switching the startup to launch in the background? Just wondered as I'm doing some bits on the tooling and I'll need a clean way of shutting down the server. We should have a set of UNIX System V startup/shutdown scripts and also the equivalent service related scripts for Windoze. I'm not sure Wrapper (http://wrapper.sf.net/) will work of not. Take a peek at it and let's discuss it. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: build test error
On 4/28/06, emicalc [EMAIL PROTECTED] wrote:
Hello,
I have a problem with the build oh servicemix-2.0.2 with maven-1.0.2.
When I start maven with no test ('maven -Dmaven.test.skip=true' command) the
build succesfully complited;
if I try to buld with test ('maven' command) the build failed; I have found
the following error in the test:
1) [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2,534 sec
[junit] [ERROR] TEST
org.servicemix.jbi.installation.ExplodedComponentInstallationTest
FAILED
Is this the problem???
Thank's to everybody
Version 2.0.2 is very out of date as it was released back in November
2005. Since that time, there have been many, many changes. I highly
recommend using the latest source either from the Subversion
repository trunk (http://servicemix.org/Source) or from a source
download (http://cvs.apache.org/repository/incubator-servicemix/distributions/).
Bruce
--
perl -e 'print unpack(u30,D0G)[EMAIL
PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT*
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
[jira] Updated: (GERONIMO-1683) Web app context-root should trim whitespace
[ http://issues.apache.org/jira/browse/GERONIMO-1683?page=all ] Erin Mulder updated GERONIMO-1683: -- Attachment: 1683-context-root-trim.patch The attached patch includes fixes this issue in tomcat-builder and jetty-builder.Includes tests. Web app context-root should trim whitespace --- Key: GERONIMO-1683 URL: http://issues.apache.org/jira/browse/GERONIMO-1683 Project: Geronimo Type: Bug Security: public(Regular issues) Components: web Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Attachments: 1683-context-root-trim.patch If you have an element like this: context-root /something /context-root Then the whitespace is included in the context root -- it becomes return space space /something instead of just /something. We should trim the whitespace. -- 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
Issues Closed: week of 04-28-2006
Project: Apache Geronimo Status: Resolved, Closed (25 items) Updated In Last: Week (7 days) ** Bug * [GERONIMO-1510] NPE in connector DConfigBeans if no config params present on connection definition instance * [GERONIMO-1932] remove config-store directories from assemblies, now that they aren't used any more * [GERONIMO-1927] Need way to disable or make invisible security when using deployer.jar * [GERONIMO-1819] Port SQL realm fix from 1.1 to HEAD * [GERONIMO-1923] Many Geronimo 1.1 configs depend on non-G1.1 ActiveMQ configs * [GERONIMO-1906] Cannot add a new connector using ActiveMQManagerGBean * [GERONIMO-1071] trust material/truststore for Jetty and Tomcat HTTPS Connectors * [GERONIMO-1491] ActiveMQ plan uses hardcoded obsolete org/apache/geronimo/ActiveMQ module name * [GERONIMO-1918] NoClassDefFoundError/ClassNotFoundException when attempting to deploy web app from console GUI * [GERONIMO-1920] [Build Break] upgrade module: Test failure: assemblies_1 files in test-data missing. * [GERONIMO-1916] Handle Delegate references can't be loaded without OpenEJB present * [GERONIMO-1655] Daytrader MDBs do not start properly * [GERONIMO-1903] Add Spring to default class ignore list * [GERONIMO-1417] [daytrader] daytrader/docs/tradeFAQ.html out of date * [GERONIMO-1910] NoSuchFieldError on deployment * [GERONIMO-1392] update additional samples redirect in geronimo website * [GERONIMO-1908] Error in executing list-modules after application failure in Geronimo * [GERONIMO-1307] JMX connector doesn't shut down cleanly ** Improvement * [GERONIMO-1520] Add product name to NetworkManager * [GERONIMO-440] Installing package in offline mode should fail if server is running * [GERONIMO-1691] Console should help configure Geronimo to hook up to Apache HTTP * [GERONIMO-1803] Manage by reference, not by name * [GERONIMO-1137] Proper DConfigBeans for Connectors * [GERONIMO-1772] Application class loader should not see server classes * [GERONIMO-1278] Upgrade to XML Beans 2.1.0 from 2.0.0
[jira] Created: (SM-417) Support for durable jms subscribers in WSN
Support for durable jms subscribers in WSN -- Key: SM-417 URL: https://issues.apache.org/activemq/browse/SM-417 Project: ServiceMix Type: New Feature Components: servicemix-wsn2005 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] Created: (SM-418) Support for clustered deployment of subscribers
Support for clustered deployment of subscribers --- Key: SM-418 URL: https://issues.apache.org/activemq/browse/SM-418 Project: ServiceMix Type: New Feature Components: servicemix-wsn2005 Reporter: Guillaume Nodet Currently, if the same subscribers is deployed on more than one WSN component (in cluster), the subscriber will receive multiple copies of the same notification. This may be related to durable subscriptions... -- 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-339) Allow configuration of subscriptions and producers with XBean
[ https://issues.apache.org/activemq/browse/SM-339?page=all ] Guillaume Nodet resolved SM-339: Fix Version: 3.0-M2 Resolution: Fixed Assign To: Guillaume Nodet Author: gnodet Date: Fri Apr 28 04:05:11 2006 New Revision: 397858 URL: http://svn.apache.org/viewcvs?rev=397858view=rev Log: SM-339: Allow configuration of subscriptions and producers with XBean for WSN Modified: incubator/servicemix/trunk/servicemix-wsn2005/src/main/java/org/apache/servicemix/wsn/spring/CreatePullPointFactoryBean.java incubator/servicemix/trunk/servicemix-wsn2005/src/main/java/org/apache/servicemix/wsn/spring/PublisherComponent.java incubator/servicemix/trunk/servicemix-wsn2005/src/main/java/org/apache/servicemix/wsn/spring/RegisterPublisherFactoryBean.java incubator/servicemix/trunk/servicemix-wsn2005/src/main/java/org/apache/servicemix/wsn/spring/SubscribeFactoryBean.java incubator/servicemix/trunk/servicemix-wsn2005/src/test/java/org/apache/servicemix/wsn/component/WSNComponentTest.java incubator/servicemix/trunk/servicemix-wsn2005/src/test/resources/org/apache/servicemix/wsn/spring.xml Allow configuration of subscriptions and producers with XBean - Key: SM-339 URL: https://issues.apache.org/activemq/browse/SM-339 Project: ServiceMix Type: Improvement Components: servicemix-wsn2005 Versions: incubation Reporter: stefan klinger Assignee: Guillaume Nodet Priority: Minor Fix For: 3.0-M2 It would be nice if I could configure some subscriptions and producers during startup using XBean -- 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
SunNameServiceTest failure on Linux
I'm trying to set up a Linux system for doing Geronimo dev in addition to my usual Windows system. When building, I'm getting a test failure running org.openejb.corba.SunNameServiceTest. Here's the failure information: error type=org.omg.CORBA.COMM_FAILUREorg.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No at com.sun.corba.se.internal.iiop.ConnectionTable.getConnection(ConnectionTable.java:148) at com.sun.corba.se.internal.iiop.ConnectionTable.getConnection(ConnectionTable.java:65) at com.sun.corba.se.internal.iiop.GIOPImpl.getConnection(GIOPImpl.java:67) at com.sun.corba.se.internal.corba.ClientDelegate.createRequest(ClientDelegate.java:652) at com.sun.corba.se.internal.corba.ClientDelegate.createRequest(ClientDelegate.java:594) at com.sun.corba.se.internal.corba.InitialNamingClient.resolve(InitialNamingClient.java:1105) at com.sun.corba.se.internal.corba.InitialNamingClient.resolveUsingBootstrapProtocol(InitialNamingClient.java:788) at com.sun.corba.se.internal.corba.InitialNamingClient.cachedInitialReferences(InitialNamingClient.java:1186) at com.sun.corba.se.internal.corba.InitialNamingClient.resolve_initial_references(InitialNamingClient.java:1079) at com.sun.corba.se.internal.corba.ORB.resolve_initial_references(ORB.java:2436) at org.openejb.corba.SunNameServiceTest.testOrb(SunNameServiceTest.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) /error I appear to be getting some sort of connection failure trying to access the naming service. I'm running this in Fedora Core 4, with the Sun JVM 1.4.2_11 JVM. The firewall and SELinux are disabled. I can't think of anything obvious that might be causing this problem. The same code builds and runs fine on Windows. Has anybody else encountered this problem? Rick
Re: [announce] Apache Geronimo welcomes Guillaume Nodet as our newest committer
Congratulations! Guillaume. Anita --- Dain Sundstrom [EMAIL PROTECTED] wrote: The Apache Geronimo PMC is proud to announce Guillaume Nodet as our newest Apache Geronimo committer, and look forward to his continued great work on XBean and the Geronimo integration with Service Mix. His work shows initiative, concern to get user feedback, empathy for problems faced by other committers and willingness to work on fixing these problems. Guillaume has consistently brought unique and very difficult use cases to the XBean project (along with patches), and it is these diverse requirements that will ultimately make XBean a success. We believe he will be an excellent addition to the project and will help foster these values in others. Please join us in congratulating Guillaume, The Apache Geronimo PMC __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Release 1.1 - Question about Java 1.5 Warning message
+ 1 for 3. Any warning during startup creates lots of doubts for a new user. Change the warning to a welcome message something like : === Geronimo, J2EE1.4 certified on JVM 1.4 === It will be nice if the createDB.bat(sh) scripts of daytrader could be modified to give the warning - You are using 1.5, This application can not be deployed because... Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: +1 on #3. We should not the JDK 1.5 concerns in the readme. I also like Dave Colasurdo's suggestion that we issue a warning message if we can detect that we are running on JDK 1.5 and CORBA EJBs are being used. Not sure how feasible (or visible) it will be to add those warnings but it would be nice to have. Joe Matt Hogstrom wrote: All, I wanted to clarify what our plan is for the JVM Check that is done to verify that a user is running on Java 1.4. If someone chooses to accept the responsibility and use Java 1.5 it would be rather annoying to have this message come out every time. I think we have three options: 1. Leave it as is (warning comes out all the time) 2. Allow someone to set a property or other mechanism to tell the server to not to issue the warning message. 3. Take the message out because 1.1 will tolerate 1.5 and we're not shipping DayTrader installed so the javax.xml.namespace.QName problem won't be visible. Personally I prefer 3 if there are no other issues. Thoughts? Matt -- 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [announce] Apache Geronimo welcomes Guillaume Nodet as our newest committer
A well deserved recognition. Way to go Guillaume!! Paul On 4/27/06, Dain Sundstrom [EMAIL PROTECTED] wrote: The Apache Geronimo PMC is proud to announce Guillaume Nodet as our newest Apache Geronimo committer, and look forward to his continued great work on XBean and the Geronimo integration with Service Mix. His work shows initiative, concern to get user feedback, empathy for problems faced by other committers and willingness to work on fixing these problems. Guillaume has consistently brought unique and very difficult use cases to the XBean project (along with patches), and it is these diverse requirements that will ultimately make XBean a success. We believe he will be an excellent addition to the project and will help foster these values in others. Please join us in congratulating Guillaume, The Apache Geronimo PMC
Re: Hi , how to starta a gbean , when server starts up
Hi, Deploying a service is pretty much done just like you are deploying a j2ee application. Provide a jar and a plan for it. Take a look at geronimo-config-1.1.xsd. Your dependencies to other configurations or jars can be defined in there. Then using the command line deployer your can deploy your service. deployer deploy /path/to/jar /path/to/plan.xml Also, I've found it helpful to look at the many examples available in the configs directory from the root of the source tree. Hope that helps. - sachin On Apr 28, 2006, at 6:59 AM, Man wrote: Hi , I like to clarify few things regarding gbean dependencies here : I have a gbean , with some dependencies and i need to start it as a independent service when server starts(i don't wanna it to go as a gbean into other's configurations) . can somebody educate me , how to go about having a gbean started when server starts and where do i mention the dependencies for this gbean. With Thanks,
Re: Hi , how to starta a gbean , when server starts up
Thanks Sachin for your quickreply !!!. Let me try to be more clear . Iam not lookingto deploy the gbean manually , What iaminterested is something like this while iam building the server from scratch , i want his gbean to beget addedinto the server as a service and when i start the server , it should be started automatically. Thanks , On 4/28/06, Sachin Patel [EMAIL PROTECTED] wrote: Hi,Deploying a service is pretty much done just like you are deploying aj2ee application.Provide a jar and a plan for it.Take a look at geronimo-config-1.1.xsd.Your dependencies to other configurationsor jars can be defined in there.Then using the command linedeployer your can deploy your service.deployer deploy /path/to/jar /path/to/plan.xml Also, I've found it helpful to look at the many examples available inthe configs directory from the root of the source tree.Hope that helps.- sachinOn Apr 28, 2006, at 6:59 AM, Man wrote: Hi , I like to clarify few things regarding gbean dependencies here : I have a gbean , with some dependencies and i need to start it as a independent service when server starts(i don't wanna it to go as a gbean into other's configurations) .can somebody educate me , how to go about having a gbean started when server starts and where do i mention the dependencies for this gbean. With Thanks,
Re: Hi , how to starta a gbean , when server starts up
Oh ok, I wasn't clean your intention. I personally don't know how best to do this, so perhaps someone else can recommend an approach. - sachin On Apr 28, 2006, at 9:23 AM, ahmed wrote: Thanks Sachin for your quick reply !!!. Let me try to be more clear . I am not looking to deploy the gbean manually , What iam interested is something like this while iam building the server from scratch , i want his gbean to be get added into the server as a service and when i start the server , it should be started automatically. Thanks , On 4/28/06, Sachin Patel [EMAIL PROTECTED] wrote: Hi, Deploying a service is pretty much done just like you are deploying a j2ee application. Provide a jar and a plan for it. Take a look at geronimo-config-1.1.xsd. Your dependencies to other configurations or jars can be defined in there. Then using the command line deployer your can deploy your service. deployer deploy /path/to/jar /path/to/plan.xml Also, I've found it helpful to look at the many examples available in the configs directory from the root of the source tree. Hope that helps. - sachin On Apr 28, 2006, at 6:59 AM, Man wrote: Hi , I like to clarify few things regarding gbean dependencies here : I have a gbean , with some dependencies and i need to start it as a independent service when server starts(i don't wanna it to go as a gbean into other's configurations) . can somebody educate me , how to go about having a gbean started when server starts and where do i mention the dependencies for this gbean. With Thanks,
[jira] Commented: (XBEAN-2) XBean should throw exceptions when a namespace can not be mapped or when an element / attribute can not be mapped
[ http://issues.apache.org/jira/browse/XBEAN-2?page=comments#action_12376936 ] Guillaume Nodet commented on XBEAN-2: - Patched checked in. http://svn.apache.org/viewcvs?view=revrev=397890 http://svn.apache.org/viewcvs?view=revrev=397892 XBean should throw exceptions when a namespace can not be mapped or when an element / attribute can not be mapped - Key: XBEAN-2 URL: http://issues.apache.org/jira/browse/XBEAN-2 Project: XBean Type: Improvement Components: spring Versions: 2.3 Reporter: Guillaume Nodet Assignee: Dain Sundstrom Attachments: XBEAN-2.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] Updated: (XBEAN-8) Support flat collections
[ http://issues.apache.org/jira/browse/XBEAN-8?page=all ] Dan Diephouse updated XBEAN-8: -- Attachment: xbean8.diff The test cases from last time didn't make it in... Support flat collections Key: XBEAN-8 URL: http://issues.apache.org/jira/browse/XBEAN-8 Project: XBean Type: New Feature Components: spring Versions: 2.2 Reporter: Dan Diephouse Assignee: Dain Sundstrom Attachments: flat.diff, xbean8.diff I would like to be able to do serviceoperation//service instead of serviceoperationsoperation//operations -- 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: Release 1.1 - Question about Java 1.5 Warning message
On 4/27/06, Aaron Mulder [EMAIL PROTECTED] wrote:
FYI, if we distribute DayTrader as a plugin, we can tag it as running
on JDK 1.4.* only, and then you won't be able to install it into a
server running on 1.5.
I think we should move the JDK 1.5 warning to a GBean we put in the
j2ee-corba configuration, so if that configuration is started for any
reason it will spew out the warning if running on JDK 1.5.
Long term this sounds like the best idea to me. If the gbean were
implemented in a generic way it could be reused by other
applications/components that have specific runtime reqs. They could
pass a list of properties (using CSVs if needed) to the gbean that get
compared (via substring) to the JVM system properties, along with the
warning text to emit if there's a mismatch.
e.g. something like:
gbean name=RuntimeCheck
class=org.apache.geronimo.system.util.RuntimeCheckGBean
attribute name=systemProperties
java.runtime.version=1.3,1.4.2
os.arch=i386
os.name=Linux
/attribute
attribute name=warningText
The runtime environment does not meet the requirements of
this application:
{$systemProperties}
Serialization errors and JNI problems may occur.
/attribute
/gbean
Could that be useful to an application like daytrader? If there's
interest in this approach (or something similar) then I am happy to
volunteer.
Thanks,
Aaron
On 4/27/06, Joe Bohn [EMAIL PROTECTED] wrote:
+1 on #3. We should not the JDK 1.5 concerns in the readme.
I also like Dave Colasurdo's suggestion that we issue a warning message
if we can detect that we are running on JDK 1.5 and CORBA EJBs are being
used. Not sure how feasible (or visible) it will be to add those
warnings but it would be nice to have.
Joe
Matt Hogstrom wrote:
All,
I wanted to clarify what our plan is for the JVM Check that is done to
verify that a user is running on Java 1.4. If someone chooses to accept
the responsibility and use Java 1.5 it would be rather annoying to have
this message come out every time.
I think we have three options:
1. Leave it as is (warning comes out all the time)
2. Allow someone to set a property or other mechanism to tell the server
to not to issue the warning message.
3. Take the message out because 1.1 will tolerate 1.5 and we're not
shipping DayTrader installed so the javax.xml.namespace.QName problem
won't be visible.
Personally I prefer 3 if there are no other issues.
Thoughts?
Matt
--
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: Hi , how to starta a gbean , when server starts up
The only way to get GBeans into the server is to include them in a Geronimo module (either an application, or a service module). The module needs to have a deployment plan that lists the GBeans as well as any dependencies. This is the same way all the core components of Geronimo are installed -- they are included in modules like j2ee-server, j2ee-system, etc. If you deploy the module normally (either during server construction or afterward) then your module (and the GBeans within it) will be started when the server starts and stopped when the server stops, unless you use one of the deployment tools to stop or undeploy the module. If you're building a server from scratch you'd probably want to use Maven to build your module, the packaging plugin to package it into a CAR file, and the assembly pluing to include that CAR file in the server. If you want to add your module to the server at any time after the assembly plugin is run, you can just use the normal deploy tool. Thanks, Aaron On 4/28/06, ahmed [EMAIL PROTECTED] wrote: Thanks Sachin for your quick reply !!!. Let me try to be more clear . I am not looking to deploy the gbean manually , What iam interested is something like this while iam building the server from scratch , i want his gbean to be get added into the server as a service and when i start the server , it should be started automatically. Thanks , On 4/28/06, Sachin Patel [EMAIL PROTECTED] wrote: Hi, Deploying a service is pretty much done just like you are deploying a j2ee application. Provide a jar and a plan for it. Take a look at geronimo-config-1.1.xsd. Your dependencies to other configurations or jars can be defined in there. Then using the command line deployer your can deploy your service. deployer deploy /path/to/jar /path/to/plan.xml Also, I've found it helpful to look at the many examples available in the configs directory from the root of the source tree. Hope that helps. - sachin On Apr 28, 2006, at 6:59 AM, Man wrote: Hi , I like to clarify few things regarding gbean dependencies here : I have a gbean , with some dependencies and i need to start it as a independent service when server starts(i don't wanna it to go as a gbean into other's configurations) . can somebody educate me , how to go about having a gbean started when server starts and where do i mention the dependencies for this gbean. With Thanks,
Re: SunNameServiceTest failure on Linux
I've never seen that. Maybe it is trying to listen on a protected port ( 1024). David Blevins, is there anything special we did to get the build working on Fedora Core? -dain On Apr 28, 2006, at 3:41 AM, Rick McGuire wrote: I'm trying to set up a Linux system for doing Geronimo dev in addition to my usual Windows system. When building, I'm getting a test failure running org.openejb.corba.SunNameServiceTest. Here's the failure information: error type=org.omg.CORBA.COMM_FAILUREorg.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No at com.sun.corba.se.internal.iiop.ConnectionTable.getConnection (ConnectionTable.java:148) at com.sun.corba.se.internal.iiop.ConnectionTable.getConnection (ConnectionTable.java:65) at com.sun.corba.se.internal.iiop.GIOPImpl.getConnection (GIOPImpl.java:67) at com.sun.corba.se.internal.corba.ClientDelegate.createRequest (ClientDelegate.java:652) at com.sun.corba.se.internal.corba.ClientDelegate.createRequest (ClientDelegate.java:594) at com.sun.corba.se.internal.corba.InitialNamingClient.resolve (InitialNamingClient.java:1105) at com.sun.corba.se.internal.corba.InitialNamingClient.resolveUsingBootst rapProtocol(InitialNamingClient.java:788) at com.sun.corba.se.internal.corba.InitialNamingClient.cachedInitialRefer ences(InitialNamingClient.java:1186) at com.sun.corba.se.internal.corba.InitialNamingClient.resolve_initial_re ferences(InitialNamingClient.java:1079) at com.sun.corba.se.internal.corba.ORB.resolve_initial_references (ORB.java:2436) at org.openejb.corba.SunNameServiceTest.testOrb (SunNameServiceTest.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) /error I appear to be getting some sort of connection failure trying to access the naming service. I'm running this in Fedora Core 4, with the Sun JVM 1.4.2_11 JVM. The firewall and SELinux are disabled. I can't think of anything obvious that might be causing this problem. The same code builds and runs fine on Windows. Has anybody else encountered this problem? Rick
[jira] Updated: (XBEAN-9) Support flat properties
[ http://issues.apache.org/jira/browse/XBEAN-9?page=all ] Guillaume Nodet updated XBEAN-9: Fix Version: 2.3 Assign To: Guillaume Nodet (was: Dain Sundstrom) Support flat properties --- Key: XBEAN-9 URL: http://issues.apache.org/jira/browse/XBEAN-9 Project: XBean Type: New Feature Components: spring Versions: 2.2 Reporter: Dan Diephouse Assignee: Guillaume Nodet Fix For: 2.3 Right now in servicemix we have to do: eip:inListener eip:exchange-target service=test:trace1 / /eip:inListener It would be much better if we could do: eip:inListener service=test:trace1 / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-4) Create a maven 2 plugin for spring mapping generation
[ http://issues.apache.org/jira/browse/XBEAN-4?page=all ] Guillaume Nodet updated XBEAN-4: Fix Version: 2.3 Assign To: Guillaume Nodet (was: Dain Sundstrom) Create a maven 2 plugin for spring mapping generation - Key: XBEAN-4 URL: http://issues.apache.org/jira/browse/XBEAN-4 Project: XBean Type: New Feature Components: spring Versions: 2.3 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.3 Attachments: XBEAN-4.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] Updated: (XBEAN-6) Fix dependencies scope
[ http://issues.apache.org/jira/browse/XBEAN-6?page=all ] Guillaume Nodet updated XBEAN-6: Fix Version: 2.3 Assign To: Guillaume Nodet (was: Dain Sundstrom) Fix dependencies scope -- Key: XBEAN-6 URL: http://issues.apache.org/jira/browse/XBEAN-6 Project: XBean Type: Bug Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.3 Attachments: XBEAN-6.patch Some dependencies do not have the right scope and this can be annoying for end users -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-2) XBean should throw exceptions when a namespace can not be mapped or when an element / attribute can not be mapped
[ http://issues.apache.org/jira/browse/XBEAN-2?page=all ] Guillaume Nodet updated XBEAN-2: Fix Version: 2.3 Assign To: Guillaume Nodet (was: Dain Sundstrom) XBean should throw exceptions when a namespace can not be mapped or when an element / attribute can not be mapped - Key: XBEAN-2 URL: http://issues.apache.org/jira/browse/XBEAN-2 Project: XBean Type: Improvement Components: spring Versions: 2.3 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.3 Attachments: XBEAN-2.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] Updated: (XBEAN-7) Inconsistent use of classloader when using spring configurations for xbean-server
[ http://issues.apache.org/jira/browse/XBEAN-7?page=all ] Guillaume Nodet updated XBEAN-7: Fix Version: 2.3 Assign To: Guillaume Nodet (was: Dain Sundstrom) Inconsistent use of classloader when using spring configurations for xbean-server - Key: XBEAN-7 URL: http://issues.apache.org/jira/browse/XBEAN-7 Project: XBean Type: Bug Components: server Versions: 2.2 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.3 Attachments: XBEAN-7.patch The ClassLoaderXmlPreprocessor redefines the classloader used by spring / xbean when loading a spring configuration file. Unfortunately, the behavior is inconsistent when using the classpath / tag and when not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release 1.1 - Question about Java 1.5 Warning message
On Apr 28, 2006, at 7:48 AM, Paul McMahan wrote:
e.g. something like:
gbean name=RuntimeCheck
class=org.apache.geronimo.system.util.RuntimeCheckGBean
attribute name=systemProperties
java.runtime.version=1.3,1.4.2
os.arch=i386
os.name=Linux
/attribute
attribute name=warningText
The runtime environment does not meet the requirements of
this application:
{$systemProperties}
Serialization errors and JNI problems may occur.
/attribute
/gbean
Could that be useful to an application like daytrader? If there's
interest in this approach (or something similar) then I am happy to
volunteer.
If you do write that, take a look at
org.apache.geronimo.kernel.config.Os.
-dain
[jira] Updated: (XBEAN-8) Support flat collections
[ http://issues.apache.org/jira/browse/XBEAN-8?page=all ] Guillaume Nodet updated XBEAN-8: Fix Version: 2.3 Assign To: Guillaume Nodet (was: Dain Sundstrom) Support flat collections Key: XBEAN-8 URL: http://issues.apache.org/jira/browse/XBEAN-8 Project: XBean Type: New Feature Components: spring Versions: 2.2 Reporter: Dan Diephouse Assignee: Guillaume Nodet Fix For: 2.3 Attachments: flat.diff, xbean8.diff I would like to be able to do serviceoperation//service instead of serviceoperationsoperation//operations -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (XBEAN-2) XBean should throw exceptions when a namespace can not be mapped or when an element / attribute can not be mapped
[ http://issues.apache.org/jira/browse/XBEAN-2?page=all ] Guillaume Nodet resolved XBEAN-2: - Resolution: Fixed XBean should throw exceptions when a namespace can not be mapped or when an element / attribute can not be mapped - Key: XBEAN-2 URL: http://issues.apache.org/jira/browse/XBEAN-2 Project: XBean Type: Improvement Components: spring Versions: 2.3 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.3 Attachments: XBEAN-2.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] Commented: (XBEAN-4) Create a maven 2 plugin for spring mapping generation
[ http://issues.apache.org/jira/browse/XBEAN-4?page=comments#action_12376958 ] Guillaume Nodet commented on XBEAN-4: - Patch applied and update poms to use the plugin http://svn.apache.org/viewcvs?view=revrev=397923 http://svn.apache.org/viewcvs?view=revrev=397898 Create a maven 2 plugin for spring mapping generation - Key: XBEAN-4 URL: http://issues.apache.org/jira/browse/XBEAN-4 Project: XBean Type: New Feature Components: spring Versions: 2.3 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.3 Attachments: XBEAN-4.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] Resolved: (XBEAN-6) Fix dependencies scope
[ http://issues.apache.org/jira/browse/XBEAN-6?page=all ] Guillaume Nodet resolved XBEAN-6: - Resolution: Fixed Revision http://svn.apache.org/viewcvs?view=revrev=397927 Fix dependencies scope -- Key: XBEAN-6 URL: http://issues.apache.org/jira/browse/XBEAN-6 Project: XBean Type: Bug Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.3 Attachments: XBEAN-6.patch Some dependencies do not have the right scope and this can be annoying for end users -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (XBEAN-7) Inconsistent use of classloader when using spring configurations for xbean-server
[ http://issues.apache.org/jira/browse/XBEAN-7?page=all ] Guillaume Nodet resolved XBEAN-7: - Resolution: Fixed Pacth applied at revision http://svn.apache.org/viewcvs?view=revrev=397924 Inconsistent use of classloader when using spring configurations for xbean-server - Key: XBEAN-7 URL: http://issues.apache.org/jira/browse/XBEAN-7 Project: XBean Type: Bug Components: server Versions: 2.2 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.3 Attachments: XBEAN-7.patch The ClassLoaderXmlPreprocessor redefines the classloader used by spring / xbean when loading a spring configuration file. Unfortunately, the behavior is inconsistent when using the classpath / tag and when not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (XBEAN-8) Support flat collections
[ http://issues.apache.org/jira/browse/XBEAN-8?page=all ] Guillaume Nodet resolved XBEAN-8: - Resolution: Fixed Support flat collections Key: XBEAN-8 URL: http://issues.apache.org/jira/browse/XBEAN-8 Project: XBean Type: New Feature Components: spring Versions: 2.2 Reporter: Dan Diephouse Assignee: Guillaume Nodet Fix For: 2.3 Attachments: flat.diff, xbean8.diff I would like to be able to do serviceoperation//service instead of serviceoperationsoperation//operations -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (XBEAN-9) Support flat properties
[ http://issues.apache.org/jira/browse/XBEAN-9?page=all ] Guillaume Nodet resolved XBEAN-9: - Resolution: Fixed Support flat properties --- Key: XBEAN-9 URL: http://issues.apache.org/jira/browse/XBEAN-9 Project: XBean Type: New Feature Components: spring Versions: 2.2 Reporter: Dan Diephouse Assignee: Guillaume Nodet Fix For: 2.3 Right now in servicemix we have to do: eip:inListener eip:exchange-target service=test:trace1 / /eip:inListener It would be much better if we could do: eip:inListener service=test:trace1 / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (XBEAN-4) Create a maven 2 plugin for spring mapping generation
[ http://issues.apache.org/jira/browse/XBEAN-4?page=all ] Guillaume Nodet resolved XBEAN-4: - Resolution: Fixed Create a maven 2 plugin for spring mapping generation - Key: XBEAN-4 URL: http://issues.apache.org/jira/browse/XBEAN-4 Project: XBean Type: New Feature Components: spring Versions: 2.3 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.3 Attachments: XBEAN-4.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
The name of key store type is hardcoded in the sources
Hello The name of Sun-specific key store type is hardcoded in the sources, so it might not work on non-Sun VMs. >From my point of view, there are two ways to fix this problem: 1. Always use BKS key store ofBouncy Castle ( http://www.bouncycastle.org) security provider, because it is open-source project. Geronimo can use BKS if I just replace JKS word to BKS of in the source of Geronimo. In this case Bouncy Castle security provider should be in class path in Geronimo. 2. Change sources so Geronimo will use a key store type which exists in VM. Key store type existing in VM can be discovered by invoking KeyStore.getDefaultType() method. Disadvantage of this way: if I build Geronimo on Sun VM, it generates JKS key store file, which might not be read by other VM, because of lack JKS key store implementation. So binary builds might not work on other VMs. Can you advise which way Geronimo should use? Nikolay Chugunov Intel Middleware Product Division .
Re: Outstanding XBean Patches...
I have checked in all outstanding patches. I will do a release 2.3 asap, unless someone has any problems with it ... Cheers, Guillaume Nodet Dan Diephouse wrote: I was wondering if someone could commit some patches for the XBean project. I just sent in a patch for two issues (XBEAN-8 and XBEAN-9) and would like to see those, and others, integrated in. Here is a summary the outstanding issues with patches that need to get committed: XBEAN-2: XBean should throw exceptions when a namespace can not be mapped or when an element / attribute can not be mapped XBEAN-4: Create a maven 2 plugin for spring mapping generation XBEAN-6: Fix dependencies scope XBEAN-7: Inconsistent use of classloader when using spring configurations for xbean-server XBEAN-8: Support flat collections XBEAN-9: Support flat properties It'd be great if someone could commit these and then we could get a release out! We at XFire would like to do a 1.1 release soon and really need some of these in there. - Dan
Re: JMS tutorial using ActiveMQ ,Tomcat and Axis
Thanks I am able to read any thing on ur site. It is in any other language? -- View this message in context: http://www.nabble.com/JMS-tutorial-using-ActiveMQ-%2CTomcat-and-Axis-t1525151.html#a4143587 Sent from the ActiveMQ - Dev forum at Nabble.com.
will multiple targets conflict?
Aaron, If no targets are specified by default the current help specifies that the the configuration will be deployed to all targets. Will this cause conflicts? i.e config store A may not be able to correctly resolve a configuration that can only be understood by config store B, as will be the case with the eclipse scenario. In the case that the app can be successfully deployed to both, how does this impact the application at runtime? If I hit an app in the browser which config store is it running off off? Does there need to be a notion of a default config store and if no targets are specified the default is used? I'm concerned with the eclipse-aware configuration store causing issues with a given server instance being used for normal deployment. - sachin
Re: [announce] Apache Geronimo welcomes Guillaume Nodet as our newest committer
On 4/28/06, Dain Sundstrom [EMAIL PROTECTED] wrote: The Apache Geronimo PMC is proud to announce Guillaume Nodet as our newest Apache Geronimo committer, and look forward to his continued great work on XBean and the Geronimo integration with Service Mix. ... Please join us in congratulating Guillaume, My pleasure - it's said taht XBean will improve rapidly now since Guillaume is in. Ehh, the commit traffic will surely increase, too ;) Welcome aboard! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: will multiple targets conflict?
On Apr 28, 2006, at 9:48 AM, Sachin Patel wrote: Aaron, If no targets are specified by default the current help specifies that the the configuration will be deployed to all targets. Will this cause conflicts? i.e config store A may not be able to correctly resolve a configuration that can only be understood by config store B, as will be the case with the eclipse scenario. In the case that the app can be successfully deployed to both, how does this impact the application at runtime? If I hit an app in the browser which config store is it running off off? Does there need to be a notion of a default config store and if no targets are specified the default is used? I'm concerned with the eclipse-aware configuration store causing issues with a given server instance being used for normal deployment. +1 -dain
Re: 1.1 Release (Version Upgrades)
Hi All, I'll be happy to work on the *RELEASE-NOTES*, there are many things in common with the documentation. I need your input to build a thorough list with all the changes (major and minor) from the previous release. We need a Summary of changes section in the release notes and that list will need to be expanded in the 1.1 documentation to cover more in detail the impact of those changes in current installation. The more complete and detailed the better. As an example, here are some of the topics that should be covered in detail on that list: - Deployment plans - Repository - Geronimo plugins - ... Any help will be very much appreciated :) Cheers! Hernan Matt Hogstrom wrote: We're nearing the end of the CTS cycle and will soon have a stable 1.1. Once we reach this critical stage we need to move into the final stages to release 1.1. Here is my proposed list. *Starting now:* 1. Code freeze for 2006/04/18 23:59 PST (except bug and performance fixes) *Once we've reached CTS stable:* (feel free to volunteer for tasks) 1. Begin changing packages to upgrade as appropriate (proposed list below) 2. Develop *Release Notes* 3. Draft a *Press Release* 4. Begin performance regression 5. SWAG a date Release Candidate 6. Test, Test, Test *After 1.1 is stable:* 1. Formalize strategy for syncing 1.1 and HEAD 2. Define a set of release goals for 1.2 and propose a target date I suggest that we define a theme for a release to help the group focus on a set of goals that will guide the work for the next release. This is not intended to be a rigid constraint but merely to provide some direction. It will also help us define a target release date to help us deliver on a consistent schedule for our users. 3. Solicit user feedback for prioritizing work Listening to our users and providing them with the features they want. 4. Aggressively update our dependent package versions to new new levels. Cheers, Matt *Version Upgrades - Matt's Suggestions* I looked at the packages out there and here is the first stab at which ones we should upgrade. Comments? *G* *Available* *Version* *Package* *Version**Version* 1.1 activemq 3.2.1 3.2.3 1.1 castor0.9.5.3 0.9.9.1 or 1.0M3 1.1 daytrader 1.1-SNAPSHOT 1.1-SNAPSHOT 1.1 derby 10.0.2.1 10.1.2.1 1.1 derby 10.1.1.0 10.1.2.1 1.1 jasper5.5.95.5.15 1.1 jasper5.5.12 5.5.15 1.1 jetty 5.1.95.1.10 1.1 openejb 2.1-SNAPSHOT 2.1-SNAPSHOT 1.1 stax 1.1.1-dev1.1.2 1.1 tomcat5.5.95.5.15 1.1 tomcat_ajp5.5.95.5.15 1.1 tranql1.2.1 1.3-SNAPSHOT 1.1 tranql_connector 1.1 1.2-SNAPSHOT
Simplify the welcome application
Can we simplify the welcome application for the server? I find the shear amount of text on the page overwhelming. I'm hoping we can push the fine detail of to secondary pages. Also, what is the strategy for easily acquiring the samples? -dain
Re: will multiple targets conflict?
Is there going to be more than one writeable config store per server? Can the default be to deploy to all writeable config stores? Aaron On 4/28/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Apr 28, 2006, at 9:48 AM, Sachin Patel wrote: Aaron, If no targets are specified by default the current help specifies that the the configuration will be deployed to all targets. Will this cause conflicts? i.e config store A may not be able to correctly resolve a configuration that can only be understood by config store B, as will be the case with the eclipse scenario. In the case that the app can be successfully deployed to both, how does this impact the application at runtime? If I hit an app in the browser which config store is it running off off? Does there need to be a notion of a default config store and if no targets are specified the default is used? I'm concerned with the eclipse-aware configuration store causing issues with a given server instance being used for normal deployment. +1 -dain
Re: Simplify the welcome application
On 4/28/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Can we simplify the welcome application for the server? I find the shear amount of text on the page overwhelming. I'm hoping we can push the fine detail of to secondary pages. Do you have a proposal for what should go on the front page and what should not? Also, what is the strategy for easily acquiring the samples? Someone was looking at that -- maybe pkashyap, I forget. It was mentioned on IRC yesterday. The deal is if you click a link to a sample that's not installed, it will explain and have a link to click here to go to the plugin download page where you can install sample XYZ or whatever. Thanks, Aaron
Re: Outstanding XBean Patches...
Woohoo! Thanks Guillaume. - Dan Guillaume Nodet wrote: I have checked in all outstanding patches. I will do a release 2.3 asap, unless someone has any problems with it ... Cheers, Guillaume Nodet Dan Diephouse wrote: I was wondering if someone could commit some patches for the XBean project. I just sent in a patch for two issues (XBEAN-8 and XBEAN-9) and would like to see those, and others, integrated in. Here is a summary the outstanding issues with patches that need to get committed: XBEAN-2: XBean should throw exceptions when a namespace can not be mapped or when an element / attribute can not be mapped XBEAN-4: Create a maven 2 plugin for spring mapping generation XBEAN-6: Fix dependencies scope XBEAN-7: Inconsistent use of classloader when using spring configurations for xbean-server XBEAN-8: Support flat collections XBEAN-9: Support flat properties It'd be great if someone could commit these and then we could get a release out! We at XFire would like to do a 1.1 release soon and really need some of these in there. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
Re: will multiple targets conflict?
The eclipse-aware config store is a subclass of the repository config- store, so yes, there would be more then one. (Currently due to it being a subclass the metadata would be written to the instance repo, but I'm thinking about moving this internally to generate inside the eclipse workspace metadata. So either way if the CLI deployed to both writeable config stores, I'm thinking there would be issues with that, so no to the second question. - sachin On Apr 28, 2006, at 1:51 PM, Aaron Mulder wrote: Is there going to be more than one writeable config store per server? Can the default be to deploy to all writeable config stores? Aaron On 4/28/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Apr 28, 2006, at 9:48 AM, Sachin Patel wrote: Aaron, If no targets are specified by default the current help specifies that the the configuration will be deployed to all targets. Will this cause conflicts? i.e config store A may not be able to correctly resolve a configuration that can only be understood by config store B, as will be the case with the eclipse scenario. In the case that the app can be successfully deployed to both, how does this impact the application at runtime? If I hit an app in the browser which config store is it running off off? Does there need to be a notion of a default config store and if no targets are specified the default is used? I'm concerned with the eclipse-aware configuration store causing issues with a given server instance being used for normal deployment. +1 -dain
Re: will multiple targets conflict?
But yes, if we can key of something else to identify the type of repo, that would be good. The primary issue is the the eclipse-aware config store can not resolve artifacts that are in a J2EE structure. It will only be able to understand the eclipse project layout, so deploying an application in a J2EE compliant structure to this repo will fail. - sachin On Apr 28, 2006, at 2:39 PM, Sachin Patel wrote: The eclipse-aware config store is a subclass of the repository config-store, so yes, there would be more then one. (Currently due to it being a subclass the metadata would be written to the instance repo, but I'm thinking about moving this internally to generate inside the eclipse workspace metadata. So either way if the CLI deployed to both writeable config stores, I'm thinking there would be issues with that, so no to the second question. - sachin On Apr 28, 2006, at 1:51 PM, Aaron Mulder wrote: Is there going to be more than one writeable config store per server? Can the default be to deploy to all writeable config stores? Aaron On 4/28/06, Dain Sundstrom [EMAIL PROTECTED] wrote: On Apr 28, 2006, at 9:48 AM, Sachin Patel wrote: Aaron, If no targets are specified by default the current help specifies that the the configuration will be deployed to all targets. Will this cause conflicts? i.e config store A may not be able to correctly resolve a configuration that can only be understood by config store B, as will be the case with the eclipse scenario. In the case that the app can be successfully deployed to both, how does this impact the application at runtime? If I hit an app in the browser which config store is it running off off? Does there need to be a notion of a default config store and if no targets are specified the default is used? I'm concerned with the eclipse-aware configuration store causing issues with a given server instance being used for normal deployment. +1 -dain
Re: Simplify the welcome application
That's right. I'm looking at the 2nd part (acquiring samples). I am encountering an error when I try to deploy the welcome configuration after I undeploy it. The error is: Error: Unable to distribute welcome-jetty-1.1-SNAPSHOT.car: java.io.IOException: Sum file already exists The stacktrace goes like this - java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(ConfigurationStoreUtil.java:43) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(ExecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryConfigurationStore.java:319) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore$$FastClassByCGLIB$$968bf00c.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) The welcome-jetty*.car being deployed is from the local repo and the plan is from configs/welcome-jetty/target/plan/plan.xml. Would appreciate any help in deploying the welcome app again. Cheers Prasad On 4/28/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 4/28/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Can we simplify the welcome application for the server? I find the shear amount of text on the page overwhelming. I'm hoping we can push the fine detail of to secondary pages. Do you have a proposal for what should go on the front page and what should not? Also, what is the strategy for easily acquiring the samples? Someone was looking at that -- maybe pkashyap, I forget. It was mentioned on IRC yesterday. The deal is if you click a link to a sample that's not installed, it will explain and have a link to click here to go to the plugin download page where you can install sample XYZ or whatever. Thanks, Aaron
Re: Simplify the welcome application
Prasad, I think you might want to deploy the war instead of the car. The command line would look something like: deploy.sh deploy applications/welcome/target/geronimo-welcome-*.war configs/welcome-jetty/target/plan/plan.xml On 4/28/06, Prasad Kashyap [EMAIL PROTECTED] wrote: That's right. I'm looking at the 2nd part (acquiring samples). I am encountering an error when I try to deploy the welcome configuration after I undeploy it. The error is: Error: Unable to distribute welcome-jetty-1.1-SNAPSHOT.car: java.io.IOException: Sum file already exists The stacktrace goes like this - java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(ConfigurationStoreUtil.java:43) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(ExecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryConfigurationStore.java:319) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore$$FastClassByCGLIB$$968bf00c.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) The welcome-jetty*.car being deployed is from the local repo and the plan is from configs/welcome-jetty/target/plan/plan.xml. Would appreciate any help in deploying the welcome app again. Cheers Prasad On 4/28/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 4/28/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Can we simplify the welcome application for the server? I find the shear amount of text on the page overwhelming. I'm hoping we can push the fine detail of to secondary pages. Do you have a proposal for what should go on the front page and what should not? Also, what is the strategy for easily acquiring the samples? Someone was looking at that -- maybe pkashyap, I forget. It was mentioned on IRC yesterday. The deal is if you click a link to a sample that's not installed, it will explain and have a link to click here to go to the plugin download page where you can install sample XYZ or whatever. Thanks, Aaron
Re: Simplify the welcome application
I swear I had tried that before. But it worked this time. Thanx Paul. Cheers Prasad On 4/28/06, Paul McMahan [EMAIL PROTECTED] wrote: Prasad, I think you might want to deploy the war instead of the car. The command line would look something like: deploy.sh deploy applications/welcome/target/geronimo-welcome-*.war configs/welcome-jetty/target/plan/plan.xml On 4/28/06, Prasad Kashyap [EMAIL PROTECTED] wrote: That's right. I'm looking at the 2nd part (acquiring samples). I am encountering an error when I try to deploy the welcome configuration after I undeploy it. The error is: Error: Unable to distribute welcome-jetty-1.1-SNAPSHOT.car: java.io.IOException: Sum file already exists The stacktrace goes like this - java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(ConfigurationStoreUtil.java:43) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(ExecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryConfigurationStore.java:319) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore$$FastClassByCGLIB$$968bf00c.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816) The welcome-jetty*.car being deployed is from the local repo and the plan is from configs/welcome-jetty/target/plan/plan.xml. Would appreciate any help in deploying the welcome app again. Cheers Prasad On 4/28/06, Aaron Mulder [EMAIL PROTECTED] wrote: On 4/28/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Can we simplify the welcome application for the server? I find the shear amount of text on the page overwhelming. I'm hoping we can push the fine detail of to secondary pages. Do you have a proposal for what should go on the front page and what should not? Also, what is the strategy for easily acquiring the samples? Someone was looking at that -- maybe pkashyap, I forget. It was mentioned on IRC yesterday. The deal is if you click a link to a sample that's not installed, it will explain and have a link to click here to go to the plugin download page where you can install sample XYZ or whatever. Thanks, Aaron
Geronimo v1.1 Documentation
Hi All, This is the new tentative structure to cover the new Geronimo release 1. Geronimo v1.1 - Summary of changes 2. Geronimo v1.1 - New features 3. Geronimo v1.1 - Installation 4. Geronimo v1.1 - Administration 4.1. Geronimo v1.1 - Tools and Commands 4.2. Geronimo v1.1 - Administration Console 4.3. Geronimo v1.1 - Administrative tasks 5. Geronimo v1.1 - Deployment plans 6. Geronimo v1.1 - Sample applications 7. Geronimo v1.1 - Migrating applications from Geronimo v1.0 I will start working on the Administration, are there any volunteers for the other sections? What other sections we should be adding? Here is the link to the confluence site http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+V1.1+-+Documentation+Draft Cheers! Hernan
Shutdown Script
Anyone had any thought on putting together a remote shutdown script? and switching the startup to launch in the background? Just wondered as I'm doing some bits on the tooling and I'll need a clean way of shutting down the server. P
Re: Simplify the welcome application
Aaron Mulder wrote: On 4/28/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Can we simplify the welcome application for the server? I find the shear amount of text on the page overwhelming. I'm hoping we can push the fine detail of to secondary pages. Do you have a proposal for what should go on the front page and what should not? It does seem like a lot of information for the initial welcome page. This will likely be the first page users hit to see if their installation is successful. We should keep it real simple with additional inks for more info.. I think we should create links for: Would you like your application to appear at this URL? and Would you like a slimmer Geronimo installation? And move the details to separate pages. Also, what is the strategy for easily acquiring the samples? Someone was looking at that -- maybe pkashyap, I forget. It was mentioned on IRC yesterday. The deal is if you click a link to a sample that's not installed, it will explain and have a link to click here to go to the plugin download page where you can install sample XYZ or whatever. I think the idea of web-based repository of plugins for geronimo is really cool and will benefit the project. From the perspective of samples, the web-based plugin repository can provide an easy way to organize and quickly install samples. However, I'm wondering if the plugin repository is really the best fit for quickly showcasing a few simple examples (e.g. servlets-examples). A typical first time user will install geronimo, go to the welcome page and probably follow a few of the links to the samples. In G1.0 it all merely works. In G1.1, the user will need to navigate several panels (e.g. Would you like to install samples, provide id/pw for console, get plugins from remote repo, start sample). I know we could probably suppress some of these panels, though the user will still likely need to make a few decisions about things they might not yet understand. Also they are dependent on network connectivity as well as remote server availability. Don't get me wrong, I think the plugin technology is a great idea and quite useful. I'm just wondering if we should continue to pre-populate the G binary image with 1 or 2 simple samples that just merely work for first time users.. Thanks -Dave- Thanks, Aaron
[jira] Created: (GERONIMO-1937) Resource reference names not trimmed for whitespace
Resource reference names not trimmed for whitespace --- Key: GERONIMO-1937 URL: http://issues.apache.org/jira/browse/GERONIMO-1937 Project: Geronimo Type: Bug Security: public (Regular issues) Components: naming Versions: 1.1 Reporter: Aaron Mulder Assigned to: Aaron Mulder Priority: Blocker Fix For: 1.1 Resource reference names appear to not be trimmed, certainly when reading from the Geronimo plan, but maybe also when reading from the J2EE plan. Trimming should be done on both values in ENCConfigBuilder -- 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-847) Better error for unmapped resource reference
[ http://issues.apache.org/jira/browse/GERONIMO-847?page=all ] Erin Mulder updated GERONIMO-847: - Attachment: 847-resource-ref-error-msg.patch This patch updates ConnectorModuleBuilder to throw an UnresolvedReferenceException and updates ENCConfigBuilder to give more helpful and specific error messages for the following error conditions: 1) Multiple matches found, no mapping in geronimo deployment plan 2) Multiple matches found, ambiguous mapping in geronimo deployment plan 3) No match found, no mapping in geronimo deployment plan 4) No match found, incorrect mapping in geronimo deployment plan Better error for unmapped resource reference Key: GERONIMO-847 URL: http://issues.apache.org/jira/browse/GERONIMO-847 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment, naming, web Versions: 1.0-M4 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Attachments: 847-resource-ref-error-msg.patch When you add a resource-ref to web.xml but not geronimo-web.xml, you get an error like: Error: Unable to distribute foo.war: Unknown or ambiguous connection factory name query: geronimo.server:J2EEServer=geronimo,J2EEApplication=null,j2eeType=JCAManagedConnectionFactory, name=jms/TestConnectionFactory,* match count: 0 It would be better if the error said Unable to resolve resource-ref 'jms/TestConnectionFactory'. It looks like there's a good message if you provide an invalid mapping value in geronimo-web.xml, but not a good message if you do not provide any mapping in geronimo-web.xml. -- 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-1875) More work to port little-g to 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1875?page=all ] David Jencks closed GERONIMO-1875: -- Resolution: Fixed This stage of minimization seems complete. If there are more problems we'll open new issues. More work to port little-g to 1.1 - Key: GERONIMO-1875 URL: http://issues.apache.org/jira/browse/GERONIMO-1875 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 Attachments: 1875_RemoveDeps.patch, 1875_RemoveDeps2.patch, 1875_RemoveDeps3.patch, 1875_axis+builder+clientDeploy.patch, 1875_axis+builder.patch, 1875_littleg.patch, 1875_openejb-deployer.diff This issue will be used to hold more patches for little-g modularization of geronimo 1.1. Some pieces: - additional plans for new configs - turning single valued references to ejb builder, axis builder, client builder, connector builder etc into something that will work. The problem is that all these builders can't be in the ancestor tree of j2ee-deployer, or we'd always be pulling them into the server. Therefore they need to be collection valued references. We can make a collection wrapper that returns a single element or null, or objects to the presence of more than one element, and use this to hold many of these 0..1 valued references. Both EarConfigBuilder and ClientModuleBuilder need this modification. - modify existing plans to remove gbeans now in the new plans. Be sure to update the defaultEnvironments as appropriate. - modify the assemblies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Testing the Installation
Yes, it should be fine. Cheers, Guillaume Nodet On 4/28/06, emicalc [EMAIL PROTECTED] wrote: At http://servicemix.org/Getting+Started; in Testing the Installation I have read that The Window's console window [...] will display something similar to the following log line if ServiceMix is up and running without any problems: [INFO] JBIContainer -- ServiceMix JBI Container http://servicemix.org/ name: defaultJBI running version: null When I start servicemix from installation directory (ex: D:\Program Files\servicemix-2.0.2) the Window's consol display the following message: ServiceMix ESB: 2.0.2 Loading ServiceMix from servicemix.xml on the CLASSPATH 12:05:47,917 INFO [JournalPersistenceAdapter] Opening journal. 12:05:48,017 INFO [JournalPersistenceAdapter] Opened journal: Active Journal: u sing 2 x 20.0 Megs at: ..\var\journal 12:05:48,017 INFO [JournalPersistenceAdapter] Journal Recovery Started. 12:05:48,147 INFO [JournalPersistenceAdapter] Journal Recovered: 0 message(s) i n transactions recovered. Is this correct? Thank's a lot -- View this message in context: http://www.nabble.com/Testing-the-Installation-t1523627.html#a4137672 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Closed: (GERONIMO-847) Better error for unmapped resource reference
[ http://issues.apache.org/jira/browse/GERONIMO-847?page=all ] David Jencks closed GERONIMO-847: - Resolution: Fixed Assign To: David Jencks (was: Aaron Mulder) Applied, thanks for the patch! Better error for unmapped resource reference Key: GERONIMO-847 URL: http://issues.apache.org/jira/browse/GERONIMO-847 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment, naming, web Versions: 1.0-M4 Reporter: Aaron Mulder Assignee: David Jencks Priority: Critical Fix For: 1.1 Attachments: 847-resource-ref-error-msg.patch When you add a resource-ref to web.xml but not geronimo-web.xml, you get an error like: Error: Unable to distribute foo.war: Unknown or ambiguous connection factory name query: geronimo.server:J2EEServer=geronimo,J2EEApplication=null,j2eeType=JCAManagedConnectionFactory, name=jms/TestConnectionFactory,* match count: 0 It would be better if the error said Unable to resolve resource-ref 'jms/TestConnectionFactory'. It looks like there's a good message if you provide an invalid mapping value in geronimo-web.xml, but not a good message if you do not provide any mapping in geronimo-web.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-847) Better error for unmapped resource reference
[ http://issues.apache.org/jira/browse/GERONIMO-847?page=comments#action_12377023 ] David Jencks commented on GERONIMO-847: --- umm, that was rev 398028 Better error for unmapped resource reference Key: GERONIMO-847 URL: http://issues.apache.org/jira/browse/GERONIMO-847 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment, naming, web Versions: 1.0-M4 Reporter: Aaron Mulder Assignee: David Jencks Priority: Critical Fix For: 1.1 Attachments: 847-resource-ref-error-msg.patch When you add a resource-ref to web.xml but not geronimo-web.xml, you get an error like: Error: Unable to distribute foo.war: Unknown or ambiguous connection factory name query: geronimo.server:J2EEServer=geronimo,J2EEApplication=null,j2eeType=JCAManagedConnectionFactory, name=jms/TestConnectionFactory,* match count: 0 It would be better if the error said Unable to resolve resource-ref 'jms/TestConnectionFactory'. It looks like there's a good message if you provide an invalid mapping value in geronimo-web.xml, but not a good message if you do not provide any mapping in geronimo-web.xml. -- 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-1938) Plugins portlet 'help' link throws PortletException
Plugins portlet 'help' link throws PortletException --- Key: GERONIMO-1938 URL: http://issues.apache.org/jira/browse/GERONIMO-1938 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.1 Reporter: Chris Cardona Not sure if this 'help' link should be removed since the 'view' link already gives a description of the portlet including how to use it. -- 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: configuration dependencies
Joe, Thanks! Sending it to the list.. --- Joe Bohn [EMAIL PROTECTED] wrote: Anita, Ahh ... now I see what you were trying to accomplish. I think this is a good question for the dev list. I personally don't think that it is important to ensure that your build includes/excludes match what is in geronimo with M1 exactly. In fact, I think what we have in M1 is really just a jumble of things that people at one time thought were needed, copied from other configurations, or whatever to get things to build. Sure, there are very specific, well placed dependencies that were added as well. But I don't think that the omissions were necessarily deliberate just as not all of the additions were deliberate (such as is likely the case with the jetty deployer in remote-deploy-tomcat). Also, based upon my recent experience with the geronimo.dependencies, even those are often the result of copied code. I didn't resolve all of these geronimo.dependencies by a long shot. I was specifically focused on making changes and validating dependencies to remove unnecessary items from inclusion in the little-G assembly. So I'm fairly sure there are still plenty of bogus geronimo.dependencies there too. Yes, with the M2 transitive dependencies we may very well be able to build and bad things could happen because of a missing geronimo.dependency when you attempt to run the server. However, I consider this no different than today where you must manually add both. It's still very possible to add one and not the other with the result being a server that cannot start (in fact I just did it this morning on my test machine). However, I think this typically speaks more to a problem in the building of the configuration rather than the building of the assembly. External dependencies by configuration must be added to the verified/added to the assemblies when the configurations are added to the assemblies. Joe anita kulshreshtha wrote: Joe, Thanks. I was trying to understand the process of assembly. so I did the following : 1. checkout ONLY top level dir, /etc and /assemblies. 2. cd j2ee-tomcat-server 3. maven I think I should be able to do this without building (modules, configs, apps) anything else. It worked fine until I got to g/javamail/../car. A jar was missing. Now why would someone in the right mind do that... It is for M2. As you said downloading everything is automatic in m2, Trying to prevent one dependency is a nightmare. It will be quite a challenge to find equivalent of g.reference, g.import and g.dependency using only 'provided' and 'exclude' and arrive at the same list as m1. You have answered my question that the javamail-transport..jar is needed for j2ee-tomcat-server. So if it gets added by M2 it will not be a bad thing! I built the server using above 3 step today, the error message is gone. But this jar is not in GERONIMO_HOME/repository/.. When I start this server bad things will happen! A similar situation is with remote-deploy-tomcat../car. it needs remote-deploy-tomcat..jar but j2ee-tomcat-server does not down load it, It depends on the fact that someone will build the configs before doing the assembly. The remote-deploy-tomcat config needs jetty-deployer and hence jetty. Why is it so? Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: ...snip -- 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (GERONIMO-1939) Server Info portlet doesn't display the 'Server Memory Usage' live graph on Internet Explorer
Server Info portlet doesn't display the 'Server Memory Usage' live graph on Internet Explorer - Key: GERONIMO-1939 URL: http://issues.apache.org/jira/browse/GERONIMO-1939 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.1 Reporter: Chris Cardona I've tested it to work on Firefox v1.5.0.2 but the graph doesn't show up on IE v6.0. -- 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-1823) Add Embedded LDAP Server Viewer Portlet
[ http://issues.apache.org/jira/browse/GERONIMO-1823?page=all ] Chris Cardona updated GERONIMO-1823: Component: console Add Embedded LDAP Server Viewer Portlet --- Key: GERONIMO-1823 URL: http://issues.apache.org/jira/browse/GERONIMO-1823 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: console Versions: 1.x Reporter: Chris Cardona Attachments: ldapMgrPortlet-Snapshot.zip, ldapMgrPortlet.patch, sample.ldif Add a new portlet for viewing the contents of the embedded directory server (Apache DS). This portlet will be under 'Misc' portlets. -- 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-1360) Misleading error for missing web deployer
[ http://issues.apache.org/jira/browse/GERONIMO-1360?page=all ] Erin Mulder updated GERONIMO-1360: -- Attachment: 1360-missing-deployer-error-msg.patch This patch changes the error message to the following: Cannot deploy the requested application module because no deployer is able to handle it. This can happen if you have disabled a deployer module, or if, for example, you are trying to deploy an EJB module on a minimal Geronimo server that does not have EJB support installed. Kind of wordy, but gives more guidance than the old message. Misleading error for missing web deployer - Key: GERONIMO-1360 URL: http://issues.apache.org/jira/browse/GERONIMO-1360 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Attachments: 1360-missing-deployer-error-msg.patch I recently experienced trouble deploying an ear file containing a war module. After a lot of head scratching (and waste of Aaron's time) I discovered that the source of the error was that the jetty-deployer wasn't started. The error returned by the deployer was Module was not a war: Adventure.war, which didn't help me a lot to say the least. The error is printed from EARConfigBuilder.java in module j2ee-builder. I'm on the 1.0 candidate build being voted about earlier today. Transcript [1] at the bottom of this mail exposes the error. I know that I'm partly to blame (the jetty-deployer is active in the default configuration), but nonetheless someone might want to create a JIRA? Kindly, Jakob Transcript [1]: $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager distribute target/plan/consumerwebsit e1.0.1.ear-plan.xml adventure1.0.3/consumerwebsite.ear Distributed org/apache/geronimo/Adventure1.0.1 ~/projects/geronimo-ab/sandbox/adventurebuilder $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager stop geronimo/jetty-deployer/1.0/car Stopped geronimo/jetty-deployer/1.0/car ~/projects/geronimo-ab/sandbox/adventurebuilder $ java -jar target/geronimo-1.0/bin/deployer.jar --user system --password manager distribute target/plan/consumerwebsit e1.0.1.ear-plan.xml adventure1.0.3/consumerwebsite.ear Error: Operation failed: Module was not a war: adventure.war --- [2] Running configurations: + geronimo/activemq-broker/1.0/car + geronimo/j2ee-server/1.0/car + geronimo/jetty-deployer/1.0/car + geronimo/ldap-realm/1.0/car + geronimo/uddi-jetty/1.0/car `- uddi-jetty @ http://jrf:8080/juddi `- uddi-db + geronimo/online-deployer/1.0/car + geronimo/activemq/1.0/car + geronimo/directory/1.0/car + geronimo/j2ee-security/1.0/car + geronimo/j2ee-deployer/1.0/car + geronimo/system-database/1.0/car + geronimo/j2ee-system/1.0/car + geronimo/rmi-naming/1.0/car + geronimo/jetty/1.0/car + geronimo/webconsole-jetty/1.0/car `- geronimo-console-standard-1.0.war @ http://jrf:8080/console-standard `- geronimo-console-framework-1.0.war @ http://jrf:8080/console + geronimo/geronimo-gbean-deployer/1.0/car -- 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: [announce] Apache Geronimo welcomes Guillaume Nodet as our newest committer
Congratulations Guillaume! John Dain Sundstrom wrote: The Apache Geronimo PMC is proud to announce Guillaume Nodet as our newest Apache Geronimo committer, and look forward to his continued great work on XBean and the Geronimo integration with Service Mix. His work shows initiative, concern to get user feedback, empathy for problems faced by other committers and willingness to work on fixing these problems. Guillaume has consistently brought unique and very difficult use cases to the XBean project (along with patches), and it is these diverse requirements that will ultimately make XBean a success. We believe he will be an excellent addition to the project and will help foster these values in others. Please join us in congratulating Guillaume, The Apache Geronimo PMC
Re: Release 1.1 - Question about Java 1.5 Warning message
Could you make it so it can be configured to be an error or a warning as
I am sure there will be use cases where a configuration should not be
started (an error produced rather than a warning) if it is known that
the runtime environment might cause loss of data etc.
John
Paul McMahan wrote:
On 4/27/06, Aaron Mulder [EMAIL PROTECTED] wrote:
FYI, if we distribute DayTrader as a plugin, we can tag it as running
on JDK 1.4.* only, and then you won't be able to install it into a
server running on 1.5.
I think we should move the JDK 1.5 warning to a GBean we put in the
j2ee-corba configuration, so if that configuration is started for any
reason it will spew out the warning if running on JDK 1.5.
Long term this sounds like the best idea to me. If the gbean were
implemented in a generic way it could be reused by other
applications/components that have specific runtime reqs. They could
pass a list of properties (using CSVs if needed) to the gbean that get
compared (via substring) to the JVM system properties, along with the
warning text to emit if there's a mismatch.
e.g. something like:
gbean name=RuntimeCheck
class=org.apache.geronimo.system.util.RuntimeCheckGBean
attribute name=systemProperties
java.runtime.version=1.3,1.4.2
os.arch=i386
os.name=Linux
/attribute
attribute name=warningText
The runtime environment does not meet the requirements of
this application:
{$systemProperties}
Serialization errors and JNI problems may occur.
/attribute
/gbean
Could that be useful to an application like daytrader? If there's
interest in this approach (or something similar) then I am happy to
volunteer.
Thanks,
Aaron
On 4/27/06, Joe Bohn [EMAIL PROTECTED] wrote:
+1 on #3. We should not the JDK 1.5 concerns in the readme.
I also like Dave Colasurdo's suggestion that we issue a warning
message
if we can detect that we are running on JDK 1.5 and CORBA EJBs are
being
used. Not sure how feasible (or visible) it will be to add those
warnings but it would be nice to have.
Joe
Matt Hogstrom wrote:
All,
I wanted to clarify what our plan is for the JVM Check that is
done to
verify that a user is running on Java 1.4. If someone chooses to
accept
the responsibility and use Java 1.5 it would be rather annoying
to have
this message come out every time.
I think we have three options:
1. Leave it as is (warning comes out all the time)
2. Allow someone to set a property or other mechanism to tell the
server
to not to issue the warning message.
3. Take the message out because 1.1 will tolerate 1.5 and we're not
shipping DayTrader installed so the javax.xml.namespace.QName
problem
won't be visible.
Personally I prefer 3 if there are no other issues.
Thoughts?
Matt
--
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] Closed: (GERONIMO-1870) Fix dependencies scope in the spec jars
[ http://issues.apache.org/jira/browse/GERONIMO-1870?page=all ] Guillaume Nodet closed GERONIMO-1870: - Fix Version: 1.1 Resolution: Fixed Assign To: Guillaume Nodet All specs jar will have to be re-released with minor versions (if the code have not changed). When releasing, do not forget to put the jars in the M2 repo so that the poms are not auto-generated by maven tools... Fix dependencies scope in the spec jars --- Key: GERONIMO-1870 URL: http://issues.apache.org/jira/browse/GERONIMO-1870 Project: Geronimo Type: Bug Security: public(Regular issues) Components: specs Versions: 1.1 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.1 Attachments: GERONIMO-specs.patch The poms for the spec jars contains some bad scope for dependencies, which means users depending on these poms will include unneeded dependencies (transitive). This is mainly critical for the j2ee jar, which will force the user to download both the j2ee jar and all its dependencies. The attached patch fixes the problem -- 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: user-apps directory
Keeping with the theme of talking to myself.. I guess it is simpler to just change the groupid in the sample deployment plans to user-apps. Of course users are free to specify any groupid they want .. but the default in the sample plans that we provide (including our documentation) will result in the user applications being separated from the geronimo plumbing by naming convention without any code impact.. -Dave- Dave Colasurdo wrote: This reminds me of a topic from a few weeks ago.. Is there a JIRA open to address separating the end user applications from the geronimo internal plumbing? Specifically, /Geronimo-1.1/repository/geronimo/ seems like a strange spot for end user applications. Searching for deployed applications seems a bit like looking for a needle in the haystack. /Geronimo-1.1/repository/ has nearly 40 directories /Geronimo-1.1/repository/geronimo has nearly 70 directories. How about a simple /Geronimo-1.1/user-apps/ that contains only deployed user applications? Thanks -Dave- David Jencks (JIRA) wrote: remove config-store directories from assemblies, now that they aren't used any more --- Key: GERONIMO-1932 URL: http://issues.apache.org/jira/browse/GERONIMO-1932 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 modify the assembly plugin to not create the bogus empty unused obsolete config-store directory
[jira] Created: (GERONIMO-1940) Bad deployment can't be undeployed
Bad deployment can't be undeployed -- Key: GERONIMO-1940 URL: http://issues.apache.org/jira/browse/GERONIMO-1940 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: Aaron Mulder Assigned to: Aaron Mulder Priority: Blocker Fix For: 1.1 If you deploy something that can't start, so it ends up in a not-started-but-not-stopped state (failed? starting?) then you can't stop or undeploy it and you're kind of stuck. For example, try deploying the attached database 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
[jira] Updated: (GERONIMO-1683) Web app context-root should trim whitespace
[ http://issues.apache.org/jira/browse/GERONIMO-1683?page=all ] Erin Mulder updated GERONIMO-1683: -- Attachment: 1683-context-root-trim-new.patch Updated patch. (Slightly cleaner, working test case.) Web app context-root should trim whitespace --- Key: GERONIMO-1683 URL: http://issues.apache.org/jira/browse/GERONIMO-1683 Project: Geronimo Type: Bug Security: public(Regular issues) Components: web Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Attachments: 1683-context-root-trim-new.patch, 1683-context-root-trim.patch If you have an element like this: context-root /something /context-root Then the whitespace is included in the context root -- it becomes return space space /something instead of just /something. We should trim the whitespace. -- 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-1941) jaxr lookup doesn't work under tomcat server
jaxr lookup doesn't work under tomcat server Key: GERONIMO-1941 URL: http://issues.apache.org/jira/browse/GERONIMO-1941 Project: Geronimo Type: Bug Security: public (Regular issues) Components: webservices Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 There are some classloader problems that result in scout not being available when looking up the jaxr connection factory in the tomcat server. I'm going to move the jaxr gbean into the uddi plan, I expect one is unlikely to be used without the other. If requested we can move it into an entirely separate plan instead. I don't think it should be in j2ee-server in any case. -- 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-1940) Bad deployment can't be undeployed
[ http://issues.apache.org/jira/browse/GERONIMO-1940?page=all ] Aaron Mulder updated GERONIMO-1940: --- Attachment: db-plan-no-deps.xml Bad deployment can't be undeployed -- Key: GERONIMO-1940 URL: http://issues.apache.org/jira/browse/GERONIMO-1940 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: db-plan-no-deps.xml If you deploy something that can't start, so it ends up in a not-started-but-not-stopped state (failed? starting?) then you can't stop or undeploy it and you're kind of stuck. For example, try deploying the attached database 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
[jira] Commented: (GERONIMO-1940) Bad deployment can't be undeployed
[ http://issues.apache.org/jira/browse/GERONIMO-1940?page=comments#action_12377050 ] Aaron Mulder commented on GERONIMO-1940: Appears that no entry is written to config.xml, but the files are in the repository, and the uninstall command gives an error. Bad deployment can't be undeployed -- Key: GERONIMO-1940 URL: http://issues.apache.org/jira/browse/GERONIMO-1940 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: db-plan-no-deps.xml If you deploy something that can't start, so it ends up in a not-started-but-not-stopped state (failed? starting?) then you can't stop or undeploy it and you're kind of stuck. For example, try deploying the attached database 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
Re: Release 1.1 - Question about Java 1.5 Warning message
How about we simply change the message to: For information about JDK 1.5 goto http://geronimo.apache.org/jdklevel Joe Bohn wrote: +1 on #3. We should not the JDK 1.5 concerns in the readme. I also like Dave Colasurdo's suggestion that we issue a warning message if we can detect that we are running on JDK 1.5 and CORBA EJBs are being used. Not sure how feasible (or visible) it will be to add those warnings but it would be nice to have. Joe Matt Hogstrom wrote: All, I wanted to clarify what our plan is for the JVM Check that is done to verify that a user is running on Java 1.4. If someone chooses to accept the responsibility and use Java 1.5 it would be rather annoying to have this message come out every time. I think we have three options: 1. Leave it as is (warning comes out all the time) 2. Allow someone to set a property or other mechanism to tell the server to not to issue the warning message. 3. Take the message out because 1.1 will tolerate 1.5 and we're not shipping DayTrader installed so the javax.xml.namespace.QName problem won't be visible. Personally I prefer 3 if there are no other issues. Thoughts? Matt
Legal files in Geronimo distributions
I have noticed that the Geronimo assemblies do not have the needed legal files, mainly the LICENSE / NOTICE files and maybe third party licenses that are not ASL 2. Cheers, Guillaume Nodet
[jira] Closed: (GERONIMO-1941) jaxr lookup doesn't work under tomcat server
[ http://issues.apache.org/jira/browse/GERONIMO-1941?page=all ] David Jencks closed GERONIMO-1941: -- Resolution: Fixed fixed rev 398050 jaxr lookup doesn't work under tomcat server Key: GERONIMO-1941 URL: http://issues.apache.org/jira/browse/GERONIMO-1941 Project: Geronimo Type: Bug Security: public(Regular issues) Components: webservices Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 There are some classloader problems that result in scout not being available when looking up the jaxr connection factory in the tomcat server. I'm going to move the jaxr gbean into the uddi plan, I expect one is unlikely to be used without the other. If requested we can move it into an entirely separate plan instead. I don't think it should be in j2ee-server in any case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1935) EJB refs fail when EJB module has no version in ConfigID
[ http://issues.apache.org/jira/browse/GERONIMO-1935?page=all ] Aaron Mulder resolved GERONIMO-1935: Resolution: Fixed EJB refs fail when EJB module has no version in ConfigID Key: GERONIMO-1935 URL: http://issues.apache.org/jira/browse/GERONIMO-1935 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, OpenEJB Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 web.xml contains: ejb-local-ref ejb-ref-nameejb/StoreManager/ejb-ref-name ejb-ref-typeSession/ejb-ref-type local-homedk.jaoo.geronimo.laptop.ejb.StoreManagerHome/local-home localdk.jaoo.geronimo.laptop.ejb.StoreManager/local ejb-linkStoreManager/ejb-link /ejb-local-ref ejb-jar.xml contains: session display-nameStore Manager Session Bean/display-name ejb-nameStoreManager/ejb-name local-homedk.jaoo.geronimo.laptop.ejb.StoreManagerHome/local-home localdk.jaoo.geronimo.laptop.ejb.StoreManager/local ejb-classdk.jaoo.geronimo.laptop.ejb.StoreManagerBean/ejb-class session-typeStateless/session-type transaction-typeContainer/transaction-type resource-ref res-ref-namejdbc/LaptopDatabase/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth res-sharing-scopeShareable/res-sharing-scope /resource-ref /session Deployment error is: Error: Unable to distribute laptopstore-ear-1.0-SNAPSHOT.ear: Could not find an EJB for reference ejb/StoreManager to a remote session bean that has the home interface dk.jaoo.geronimo.laptop.ejb.StoreManagerHome and the remote interface dk.jaoo.geronimo.laptop.ejb.StoreManager -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1684) server does not start if openejb-jar.xml activation-config had whitespace in values
[ http://issues.apache.org/jira/browse/GERONIMO-1684?page=all ] Aaron Mulder resolved GERONIMO-1684: Resolution: Fixed server does not start if openejb-jar.xml activation-config had whitespace in values --- Key: GERONIMO-1684 URL: http://issues.apache.org/jira/browse/GERONIMO-1684 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Deployed an EAR with an EJB JAR with a MDB. The activation-config property names had whitespace around them: activation-config-property-name SomeValue /activation-config-property-name The application deployed successfully. However, Geronimo was hosed. During startup it complained that SomeValue was an invalid GBean property, or something along those lines. There appear to be 2 bugs here: 1) Whitespace should be stripped from activation config property names (and values, I expect) 2) When generating the ActivationSpec GBean, we should validate that every property exists on the class (and if possible, confirm that the requested value can actually be set). It's critical to raise a deployment exception rather than deploy correctly and barf on every startup. -- 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: Release 1.1 - Question about Java 1.5 Warning message
+1 - sachin On Apr 28, 2006, at 9:02 PM, Matt Hogstrom wrote: How about we simply change the message to: For information about JDK 1.5 goto http://geronimo.apache.org/jdklevel Joe Bohn wrote: +1 on #3. We should not the JDK 1.5 concerns in the readme. I also like Dave Colasurdo's suggestion that we issue a warning message if we can detect that we are running on JDK 1.5 and CORBA EJBs are being used. Not sure how feasible (or visible) it will be to add those warnings but it would be nice to have. Joe Matt Hogstrom wrote: All, I wanted to clarify what our plan is for the JVM Check that is done to verify that a user is running on Java 1.4. If someone chooses to accept the responsibility and use Java 1.5 it would be rather annoying to have this message come out every time. I think we have three options: 1. Leave it as is (warning comes out all the time) 2. Allow someone to set a property or other mechanism to tell the server to not to issue the warning message. 3. Take the message out because 1.1 will tolerate 1.5 and we're not shipping DayTrader installed so the javax.xml.namespace.QName problem won't be visible. Personally I prefer 3 if there are no other issues. Thoughts? Matt
[jira] Commented: (GERONIMO-1680) MDB without activation-config in openejb-jar.xml silently fails
[ http://issues.apache.org/jira/browse/GERONIMO-1680?page=comments#action_12377062 ] Aaron Mulder commented on GERONIMO-1680: Upon consideration, this doesn't seem so straightforward. - We don't know what the JMS provider is, so we don't know which activation-config settings are sufficient for it to be working (though ActivationSpec can be validated) - The settings can be provided in ejb-jar.xml (in the message-driven-bean/activation-config area), and we don't know which of *those* settings might be sufficient - If a message-destination-link is specified, that needs to be decoded to an admin object, and the physical name needs to be pulled out of that (that's a product-specific property). Here's what I propose: - Create a Map to hold the activation config settings - Look up the ActivationSpec and determine whether it's class name is org.activemq.ra.ActiveMQActivationSpec - If so, do the admin object arithmatic and pop that value into destination in the map - Write all the values from ejb-jar.xml into the map - Write all the values from openejb-jar.xml into the map - Iterate the map and try to apply all the properties to the ActivationSpec - Temporarily instantiate the ActivationSpec, apply all the properties, and validate it MDB without activation-config in openejb-jar.xml silently fails --- Key: GERONIMO-1680 URL: http://issues.apache.org/jira/browse/GERONIMO-1680 Project: Geronimo Type: Bug Security: public(Regular issues) Components: ActiveMQ, OpenEJB Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 I created a queue and sent a couple messages to it. Then I created an MDB with a message-destination-type of javax.jms.Queue and a message-destination-link pointing to a message-destination with the name of the Queue. It seems like this is enough information to point the MDB to that queue, assuming that openejb-jar.xml lists the resource adapter for the MDB. This deployed successfully, but no messages were received by the MDB. Adding an activation-config section to openejb-jar.xml fixed the problem -- the pending messages were received during deployment. One of these two issues strikes me as a bug: 1) Why wasn't the MDB hooked up to the queue without needing an activation-config block in openejb-jar.xml? 2) If that's an error, why is activation-config optional for an MDB in openejb-jar.xml and why didn't it cause a deployment error? In any case, I think deployment should always fail if an MDB is not actually hooked up to a destination. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1931) Deployers and the deploying classes are in separate class loader hierarchies
[ http://issues.apache.org/jira/browse/GERONIMO-1931?page=comments#action_12377065 ] Dain Sundstrom commented on GERONIMO-1931: -- The deployment context creates a private SimpleConfigurationManager. I believe that we need a sub-class of SimpleConfigurationManager that gets the main geronimo ConfiguationManager as an argument. Then any time we are checkin if a configuration exists, we first check the main geronimo ConfigurationManager. This will cause the new private configuration manager to see all currently loaded configurations in the server, and since the deployer is clearly already loaded it will see the same classes as the deployer. Deployers and the deploying classes are in separate class loader hierarchies Key: GERONIMO-1931 URL: http://issues.apache.org/jira/browse/GERONIMO-1931 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Dain Sundstrom Fix For: 1.2 The deployers are loaded from the main KernelConfiguraitonManager, where as when we deploy the new deployments are loaded from a private SimpleConfigurationManager. This means two classloaders are completely separate and deployers see different versions of the spec classes. Therefor, the deployers can't make use of instanceof and can use code like this: TimedObject.class.inAssignable(beanClass) This makes deployers unnecessarily complex and error prone. This can easily be addressed by having the private SimpleConfigurationManager in the DeploymentContext first check main KernelConfigurationManager to see if the configuration exists before reloading it from disk. -- 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
