Re: [jira] Commented: (AMQ-684) Fatal bug: JMS Send message will be bloc
How to deal with this bug.Can't not more than one reciving client connecte to one queue.Otherwise the all send clients will be blocked. -- View this message in context: http://www.nabble.com/-jira-Created%3A-%28AMQ-684%29-Fatal-bug%3A-JMS-Send-message-will-be-blocked%2Cwhen-two-or-more-recive-client-reciving-one-queue-destation.-t1422567.html#a4115819 Sent from the ActiveMQ - Dev forum at Nabble.com.
RE: Openwire C Client.
Hi Vik, Is this the latest? Dated April 13th..? Is it declared release candidate yet? http://people.apache.org/~chirino/incubator-activemq-4.0-RC3/distributions/ I read a post by you on the forum with a pending issue with AMQ-RC3 and the consumer hanging if there is more than one message on the queue. Is that something I need to be concerned about. Please advise. Thanks very much, - Sunil -- View this message in context: http://www.nabble.com/Openwire-C-Client.-t1506711.html#a4127417 Sent from the ActiveMQ - Dev forum at Nabble.com.
Avoid blocking producers
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] Commented: (AMQ-694) Probblem with messageSelector in 4.0 M3
[ https://issues.apache.org/activemq/browse/AMQ-694?page=comments#action_36107 ] james strachan commented on AMQ-694: I was wondering how you thought the string was being cut short? You could try patch the selector test case to add some specific messages and selectors you are using... https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/selector/SelectorTest.java Probblem with messageSelector in 4.0 M3 -- Key: AMQ-694 URL: https://issues.apache.org/activemq/browse/AMQ-694 Project: ActiveMQ Type: Bug Versions: 4.0 M4 Reporter: hailima I am using 4.0 M3 and create a durable consumer with JMS API createDurableSubscriber(Topic topic, java.lang.String name, java.lang.String messageSelector, boolean noLocal). I found that ActiveMQ behaves very strange when too long string is assigned to messageSelector. The ActiveMQ is Ok if I cut the string to short. Anyone had this experience before? Any solution fo it? Here is my long string: ehs.handler.event.type.email_sp=event_type\='email_unsub_promotion' or event_type\='email_unsub_promotion_dne' or event_type\='email_user_sign_up' or event_type\='email_user_sign_up_er' or event_type\='email_registration_confirm' or event_type\='email_client_approved_offerr' or event_type\='email_certificate_received' or event_type\='email_gift_card_redeemed' or event_type\='email_password_lost' or event_type\='email_resend_sign_up' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-696) Client: XXX already connected exception when connection started after consumers added
Client: XXX already connected exception when connection started after consumers
added
-
Key: AMQ-696
URL: https://issues.apache.org/activemq/browse/AMQ-696
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0 RC 2, 4.0 RC3
Environment: WinXP
Reporter: Craig Day
While using the new Spring-2.0 DefaultMessageListenerContainer I can reliably
reproduce the following exception on the broker side which usually results in a
hang on the client side:
The broker logs the following exception:
INFO Service- Sync error occurred:
javax.jms.InvalidClientIDException: Broker: localhost - Client:
ID:inspiron-1410-114619274
7453-2:1 already connected
javax.jms.InvalidClientIDException: Broker: localhost - Client:
ID:inspiron-1410-1146192747453-2:1 already connected
at
org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:154)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:65)
at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:69)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:65)
at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:77)
at
org.apache.activemq.broker.AbstractConnection.processAddConnection(AbstractConnection.java:500)
at
org.apache.activemq.broker.jmx.ManagedTransportConnection.processAddConnection(ManagedTransportConnection.java:82)
at
org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:106)
at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:196)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:93)
at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:70)
at
org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:114)
at
org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:139)
at java.lang.Thread.run(Thread.java:595)
I have extrapolated the sequence of calls that DefaultMessageListenerContainer
is making and managed to produce a simple test case that reproduces the problem:
import junit.framework.TestCase;
import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.activemq.command.ActiveMQQueue;
import javax.jms.*;
public class TestActiveMQ extends TestCase {
public void testConnectionFactory() throws Exception {
final ActiveMQConnectionFactory cf = new
ActiveMQConnectionFactory(tcp://localhost:61616);
final ActiveMQQueue queue = new ActiveMQQueue(testqueue);
final Connection conn = cf.createConnection();
Runnable r = new Runnable() {
public void run() {
try {
Session session = conn.createSession(false, 1);
MessageConsumer consumer = session.createConsumer(queue,
null);
Message msg = consumer.receive(1000);
} catch (JMSException e) {
e.printStackTrace();
}
}
};
new Thread(r).start();
conn.start();
try {
synchronized (this) {
wait(3000);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
Let us know if you need anymore information. Dont want to scrub ActiveMQ from
my list of candidates If I can help it.
cheers
craig
--
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: CMS C++ client compatibility on Solaris
we sale used knitting and textile mc. we want contact mr vikram dhawan from delhi. wbr [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/CMS-C%2B%2B-client-compatibility-on-Solaris-t1431864.html#a4134891 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Resolved: (SM-409) Do not assume that first part of multi mime message is xml
[ https://issues.apache.org/activemq/browse/SM-409?page=all ] Guillaume Nodet resolved SM-409: Fix Version: 3.0-M2 (was: incubation) Resolution: Fixed Assign To: Guillaume Nodet Author: gnodet Date: Thu Apr 27 02:43:07 2006 New Revision: 397492 URL: http://svn.apache.org/viewcvs?rev=397492view=rev Log: SM-409: Do not assume that first part of multi mime message is xml Patch provided by Stefan Klinger, thx ! Modified: incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/marshalers/SoapReader.java incubator/servicemix/trunk/servicemix-soap/src/test/java/org/apache/servicemix/soap/marshalers/SoapMessageMarshalerTest.java Do not assume that first part of multi mime message is xml -- Key: SM-409 URL: https://issues.apache.org/activemq/browse/SM-409 Project: ServiceMix Type: Improvement Components: servicemix-soap Versions: incubation Reporter: stefan klinger Assignee: Guillaume Nodet Priority: Minor Fix For: 3.0-M2 Attachments: servicemix-soap-diff.txt Currently, the SoapReader expects the start part to be of xml format. If that part does not exist, it assumes it's the first part. I would prefer that it checks for xml parts and uses the first one it finds in that case. If none are found, insert a dummy source e.g. payload/ similar to the lightweight HttpMarshaler. -- 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-413) access message exchange properties in e.g. content-based routing XPath expressions of servicemix-eip
access message exchange properties in e.g. content-based routing XPath expressions of servicemix-eip Key: SM-413 URL: https://issues.apache.org/activemq/browse/SM-413 Project: ServiceMix Type: Improvement Components: servicemix-eip Versions: 3.0 Reporter: Peter Klotz Fix For: 3.0 in the routing patterns of servicemix-eip e.g. the content-based router, it seems that one cannot access ME properties only the ME content. It would be a nice feature if one could e.g. set a property in a transformer component and make use of it in routing so that one has a bit of context information available in the patterns, not only the content. In the content-based router one could e.g. access properties by $name_of_property in the XPath expressions. There are two ways to implement that: * create a custom predicate that can check a property on the exchange (with a regular expression maybe) * create an xpath function, configure it on the XPathPredicate and write a xpath expression using it The first one is easier of course and it could be combined with an xpath expression by implementing boolean predicates (or, and, xor, not...) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-414) SourceTransformer cant trans form to DOM with non US ASCI I characters like 'ä' or 'ü'
[
https://issues.apache.org/activemq/browse/SM-414?page=comments#action_36106 ]
Juergen Mayrbaeurl commented on SM-414:
---
Since my Eclipse setup is getting better and better, I think I could provide a
patch for the SourceTransformer class soon. Anyone interested?
Kind regards
Juergen
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
Priority: Blocker
Fix For: 3.0, incubation
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
Re: Implementing Global JNDI
I agree with what Dain said. I also believe that as the spec says the J2EE component enviroment should not be writable and we need not provide any option for that either. It is not necessary. Apps can bind to other namespaces.On 4/26/06, Dain Sundstrom [EMAIL PROTECTED] wrote: Are you planning on making the J2EE component enviroment (java:comp/env) writable?I can see making the global tree writable, but amconcerned about making the component environment itself writable.The J2EE 1.4 spec page 64 states:The container must ensure that the application component instanceshave onlyread access to their environment variables. The container must throw thejavax.naming.OperationNotSupportedException from all the methods of thejavax.naming.Context interface that modify the environment namingcontextand its subcontextsI suppose we could add an optional flag for non-compliantapplications to allow them to modify their environment, but I think the default for the component environment should be read-only.BTW, I am in favor of making everything else writable.-dainOn Apr 26, 2006, at 6:32 AM, Manu George wrote: Hi, Guillaume I guess if a writable context is implemented still the approach given above should work. As we will be using the ENCConfigBuilder only to populate the ENC during startup the interfaces can be used to refer to the gbeans representing the deployed artefacts. Whatever we will be writing to context from apps would be done after startup of server and lost at shutdown.So there would not be any problem due to geronimo using interfaces to get the GBean names as what we will be adding at runtime will not be gbeans and we will not use ENCConfigBuilder.Am I right? Now a new property for jndiname will also be required in the plans for the connectors. P.S.This property was actually present in the older versions of geronimo but was removed. I also remember david jencks mentioning in the mailing list that he had a working implementation of a context which he removed for some reason. Thanks Manu On 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: When a JNDI context is created for a given configuration, the interface name is used to determine the name of the gbean that will be mapped to this JNDI reference (and to create a proxy ?). Take a look at o.a.g.naming.ENCConfigBuilder#addResourceRefs. But I guess this is irrelevant if the objects are bound when they are created. Btw, should the global JNDI tree be read-only, or read-write ? IMHO, a read-write global JNDI tree would be very usefull. Cheers, Guillaume Nodet Manu George wrote:Thanks David. Guillaume , Which proxy in the JNDI Tree are you referring where geronimo requires the main interface name?Are you speaking of UserTransaction etc? I thought those were standard names that we can use to access them and will not be provided in DD? Please clarify and correct me if I am wrong. Thanks Manu On 4/25/06, *David Jencks* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: It's required for corba ejb references. david jencks On Apr 25, 2006, at 7:34 AM, Manu George wrote: Hi, I have a question regarding one of the objects present in the current application local JNDI Context. What is the HandleDelegate entry for? Thanks Manu
Re: Implementing Global JNDI
Comments inlineOn 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Looking more closely, it seems I was wrong.Gbeans with a j2eeType=JCAManagedConnectionFactory have aconnectionFactoryInterface attribute that gives the name of the maininterface to use when binding the object to the JNDI context. For EJB, GBeans with a j2eeType=StatelessSessionBean (or EntityBean ...)have attributes for the home and business interfaces.So i guess it should be ok. great Another way to handle that would be to bind the resource to the globalJNDI tree when the resource is created: each configuration would contain a list of gbeans to bind in the jndi tree when the configuration isloaded.Else, we will need some listener to listen to gbeans creation /destruction so that we can bind / unbind them from the global jndi context. Binding the resource during creation seems to be the simpler way. But what about the next time the server starts up. How is the context initialised? Do we populate during startup of each resource or application again or is persistence used in some way? In the case of listeners the above problem won't arise. A few questions: * I' m wondering how the global JNDI context will coexist with the existing ENC context, especially if the global jndi context isread-write ... Maybe there is no need for a local jndi context ... Yes that is a question i also have :-) . The local jndi context allows us to have app specific contexts and this has some advantages. A global jndi also has some advantages. Probably by default we can use the local context and if the user specifies a custom factory the global one or vice versa. * what is the purpose of the jndiname property ? If this is the key fora gbean in the jndi tree, I thought we could use the name attribute of the gbean: jdbc/TradeDataSource , jms/QueueConnectionFactory. These names can also be TradeDatasource so then we may need to add jdbc and if jdbc is there in the name as you mentioned do we need to add jdbc to the name or not. These are a few issues which made me propose the jndiName property . * what about conflicting names for JCA resources... currently there isnothing to prevent deploying JCA resource (or other resources that would be bound to jndi) with the same nameI think deployment should fail with an resource already bound exception. Not sure if this or any other validation is implemented for the local context. Thanks Manu
Re: Help!!! Problems using KernelManagementHelper got from getRemoteKernelManager()
Hi Aron, The code chunk from my first e-mail runs fine with G1.0 . Some of the recent changes might have broken the KernelDelegate. I will try to create a test client and post it to the dev-list. Thanks, VamsiOn 4/25/06, Aaron Mulder [EMAIL PROTECTED] wrote: Well, maybe I spoke too soon.After thinking more about it, I guessthere are two options:1) Create your own GBean to run on the server side, where your clientgives simple commands and the GBean does all the work interfacing with the server components, so that there's no serialization involved toreturn a J2EEServer, etc.2) It may be that it's not as hard as I'm imagining to convert GBeanarguments and return types to AbstractNames and vice versa in the server and the proxies.Can you post a simple test client that getsthe servers from a domain or whatever and curently blows up?Thatwould make it easier to evaluate this kind of change.Thanks, Aaron On 4/25/06, Aaron Mulder [EMAIL PROTECTED] wrote: I don't think there's going to be a fix for 1.1 -- if a method returns a GBean we don't have a way to serialize it to the client.For 1.2 I think we can work some magic in the proxies, and/or switch to a different protocol altogether. Thanks, Aaron On 4/25/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I am running the following piece of code. KernelManagementHelper mgr = KernelManagementHelper.getRemoteKernelManager (localhost, system, manager); J2EEDomain domain = mgr.getDomains()[0]; String[] servers = domain.getServers(); System.out.println(servers[0]); J2EEServer[] j2eeServers = domain.getServerInstances(); System.out.println(j2eeServers[0]); domain.getServers() runs fine, whereas, domain.getServerInstances() throws an exception.Please suggest a fix or a workaround for this problem. -Vamsi -- java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.geronimo.management.geronimo.J2EEServer$$EnhancerByCGLIB$$d620c0d0 at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:207) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientUnmarshaller.chain(ClientUnmarshaller.java:65) at mx4j.remote.rmi.ClientUnmarshaller.invoke (ClientUnmarshaller.java:54) at $Proxy0.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientExceptionCatcher.invoke(ClientExceptionCatcher.java:40) at $Proxy0.invoke(Unknown Source) at org.apache.geronimo.system.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:880) at org.apache.geronimo.system.jmx.KernelDelegate.getAttribute(KernelDelegate.java :485) at org.apache.geronimo.kernel.basic.KernelGetAttributeInvoker.invoke(KernelGetAttributeInvoker.java:36) at org.apache.geronimo.system.jmx.JMXProxyMethodInterceptor.intercept (JMXProxyMethodInterceptor.java:89) at org.apache.geronimo.management.geronimo.J2EEDomain$$EnhancerByCGLIB$$45e3ccef.getServerInstances(generated) at PeekRemoteKernel.main (PeekRemoteKernel.java:19) Caused by: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.geronimo.management.geronimo.J2EEServer$$EnhancerByCGLIB$$d620c0d0 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1278) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1603) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1271) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at sun.rmi.server.UnicastRef.unmarshalValue (UnicastRef.java:297) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:146) ... 23 more Caused by: java.io.NotSerializableException: org.apache.geronimo.management.geronimo.J2EEServer$$EnhancerByCGLIB$$d620c0d0 at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.writeArray(Unknown Source) at java.io.ObjectOutputStream.writeObject0 (Unknown Source) at java.io.ObjectOutputStream.writeObject(Unknown Source) at sun.rmi.server.UnicastRef.marshalValue(Unknown Source) at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at
[jira] Commented: (GERONIMO-1451) A new TCP listener for ActiveMQ is not persisting across server startups
[ http://issues.apache.org/jira/browse/GERONIMO-1451?page=comments#action_12376661 ] Vamsavardhana Reddy commented on GERONIMO-1451: --- Server built from 1.1 branch revision 397465. Adding a new JMS TCP Listener throws the following exception: 12:55:49,538 ERROR [JMSConnectorPortlet] Unable to process portlet action java.lang.IllegalArgumentException: GBeanInfo must have a source class set at org.apache.geronimo.system.configuration.GBeanOverride.init(GBeanOverride.java:76) at org.apache.geronimo.system.configuration.LocalAttributeManager.addGBean(LocalAttributeManager.java:320) at org.apache.geronimo.system.configuration.LocalAttributeManager$$FastClassByCGLIB$$b20ef545.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) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.PersistentConfigurationList$$EnhancerByCGLIB$$2028d0ce.addGBean(generated) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager.addGBeanToConfiguration(EditableKernelConfigurationManager.java:127) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager.addGBeanToConfiguration(EditableKernelConfigurationManager.java:60) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager$$FastClassByCGLIB$$daeffab3.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) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$36b747dd.addGBeanToConfiguration(generated) at org.activemq.gbean.management.ActiveMQManagerGBean.addConnector(ActiveMQManagerGBean.java:207) at org.activemq.gbean.management.ActiveMQManagerGBean$$FastClassByCGLIB$$a78b116e.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) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQManager$$EnhancerByCGLIB$$6fa67101.addConnector(generated) at org.apache.geronimo.console.util.PortletManager.createJMSConnector(PortletManager.java:274) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:80) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at
How to make ObjectInputStream to use a specific ClassLoader
Hi, I am trying to read an object from file using ObjectInputStream. The readObject method is throwing a ClassNotFoundException. How do I make ObjectInputStream to use a different ClassLoader which can load this class? Thanks, Vamsi
Re: How to make ObjectInputStream to use a specific ClassLoader
On Apr 27, 2006, at 12:45 AM, Vamsavardhana Reddy wrote: Hi, I am trying to read an object from file using ObjectInputStream. The readObject method is throwing a ClassNotFoundException. How do I make ObjectInputStream to use a different ClassLoader which can load this class? See ObjectInputStreamExt in the kernel module thanks david jencks Thanks, Vamsi
Re: Implementing Global JNDI
I'm not convinced this discussion has got to the hard parts yet :-) I hope there turn out not to be any :-)Please don't change stuff in the read-only java:comp/env context since it is pretty much completely specified by the spec. Note also that according to the spec a j2ee compliant app will only use this jndi context, and only use the entries defined in the j2ee deployment descriptors.I think you can use a lot of the jndi infrastructure we already have including the geronimo context and the references to jca connection factories, ejbs, etc. The missing part is how to get these references bound into your context. One approach is to write gbeans that install a reference when started and remove it when stopped. I would start by just including these as plain gbeans in plans, and once that works consider modifying the builders to add them automatically based on xml in the geronimo plans.An alternative might be to investigating using say Directory to persist the references directly. I don't know enough about ldap to know if this makes any sense at all.thanksdavid jencksOn Apr 26, 2006, at 11:56 PM, Manu George wrote:Comments inlineOn 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Looking more closely, it seems I was wrong.Gbeans with a j2eeType=JCAManagedConnectionFactory have aconnectionFactoryInterface attribute that gives the name of the maininterface to use when binding the object to the JNDI context. For EJB, GBeans with a j2eeType=StatelessSessionBean (or EntityBean ...)have attributes for the home and business interfaces.So i guess it should be ok. great Another way to handle that would be to bind the resource to the globalJNDI tree when the resource is created: each configuration would contain a list of gbeans to bind in the jndi tree when the configuration isloaded. Else, we will need some listener to listen to gbeans creation /destruction so that we can bind / unbind them from the global jndi context. Binding the resource during creation seems to be the simpler way. But what about the next time the server starts up. How is the context initialised? Do we populate during startup of each resource or application again or is persistence used in some way? In the case of listeners the above problem won't arise. A few questions: * I' m wondering how the global JNDI context will coexist with the existing ENC context, especially if the global jndi context isread-write ... Maybe there is no need for a local jndi context ... Yes that is a question i also have :-) . The local jndi context allows us to have app specific contexts and this has some advantages. A global jndi also has some advantages. Probably by default we can use the local context and if the user specifies a custom factory the global one or vice versa. * what is the purpose of the jndiname property ? If this is the key fora gbean in the jndi tree, I thought we could use the name attribute of the gbean: "jdbc/TradeDataSource" , "jms/QueueConnectionFactory". These names can also be TradeDatasource so then we may need to add jdbc and if jdbc is there in the name as you mentioned do we need to add jdbc to the name or not. These are a few issues which made me propose the jndiName property . * what about conflicting names for JCA resources... currently there isnothing to prevent deploying JCA resource (or other resources that would be bound to jndi) with the same nameI think deployment should fail with an resource already bound exception. Not sure if this or any other validation is implemented for the local context. Thanks Manu
[jira] Commented: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=comments#action_12376672 ] David Jencks commented on GERONIMO-1518: Dain and I think that it would be better to have a NestedJarRepository and not modify the existing repository classes or config store classes. I'm not sure if dain is planning on implementing this right away. Installer - only copy jars needed by selected configuration --- Key: GERONIMO-1518 URL: http://issues.apache.org/jira/browse/GERONIMO-1518 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: installer Versions: 1.2, 1.1 Reporter: erik daughtrey Assignee: Dain Sundstrom Attachments: installer-G1518.patch.gz, installer-jar-refactor-1.0.1.patch, installer-jar-refactor.patch, installer.G1518-2.patch.gz Install configuration using installer jar as source repository. -- 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: How to make ObjectInputStream to use a specific ClassLoader
Thank you David. -VamsiOn 4/27/06, David Jencks [EMAIL PROTECTED] wrote: On Apr 27, 2006, at 12:45 AM, Vamsavardhana Reddy wrote: Hi, I am trying to read an object from file using ObjectInputStream. The readObject method is throwing a ClassNotFoundException.How do I make ObjectInputStream to use a different ClassLoader which can load this class?See ObjectInputStreamExt in the kernel modulethanksdavid jencks Thanks, Vamsi
[jira] Updated: (SM-409) Do not assume that first part of multi mime message is xml
[ https://issues.apache.org/activemq/browse/SM-409?page=all ] stefan klinger updated SM-409: -- Attachment: servicemix-soap-diff.txt This diff file fixes the problem by checking for the start tag of a multipart mime message , if it does exist then use the xml as the message source. If it doesn't exist, it checks for all other mime parts for xml, and uses the first xml it comes across as the message source. if no xml exist, a dummy payload message is inserted. Also includes a test case. Do not assume that first part of multi mime message is xml -- Key: SM-409 URL: https://issues.apache.org/activemq/browse/SM-409 Project: ServiceMix Type: Improvement Components: servicemix-soap Versions: incubation Reporter: stefan klinger Priority: Minor Fix For: incubation Attachments: servicemix-soap-diff.txt Currently, the SoapReader expects the start part to be of xml format. If that part does not exist, it assumes it's the first part. I would prefer that it checks for xml parts and uses the first one it finds in that case. If none are found, insert a dummy source e.g. payload/ similar to the lightweight HttpMarshaler. -- 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
Running jsp-examples plugin
I ran the following test with today's build : 1. From console click plugins -- Search Plugins -- Jakarta JSP Examples -- install plugin -- start g/jsp-examples../car 2. Web App Wars -- stop -- uninstall (jsp-examples) 3. repeat 1. After clicking on 'plugins' the warnings are printed. The car is installed and started successfully and works. an error occurs in step2. The stack trace appears during 'start ' in step 3. Thanks Anita Web Applications: http://a-680de82293e44:8080/ http://a-680de82293e44:8080/console http://a-680de82293e44:8080/console-standard http://a-680de82293e44:8080/remote-deploy Geronimo Application Server started 10:08:38,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb AppContext in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplicatio n=null,j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 10:08:38,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon text in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null ,j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 10:08:38,656 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb AppContext in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null ,j2eeType=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 10:08:38,656 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon text in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeT ype=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 10:09:10,390 INFO [DownloadCARHandler] 10:09:10,890 INFO [DWRServlet] retrieved system configuration file: sun.net.www.protocol.jar.JarURL [EMAIL PROTECTED] 10:09:11,406 INFO [DownloadCARHandler] 10:09:11,406 INFO [DownloadCARHandler] Installation finished 10:12:06,968 ERROR [LocalAttributeManager] Trying to stop unknown configuration: geronimo/jsp-exampl es-tomcat/1.1-SNAPSHOT/car 0:14:29,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb ppContext in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplicatio =null,j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 0:14:29,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon ext in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 0:14:29,609 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb ppContext in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null j2eeType=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 0:14:29,609 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon ext in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeT pe=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 0:14:52,718 INFO [DownloadCARHandler] 0:14:53,718 INFO [DownloadCARHandler] 0:14:53,718 INFO [DownloadCARHandler] Installation finished 0:14:58,609 ERROR [ResultsHandler] Unable to start configuration geronimo/jsp-examples-tomcat/1.1-S APSHOT/car rg.apache.geronimo.kernel.config.LifecycleException: load of geronimo/jsp-examples-tomcat/1.1-SNAPS OT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConf gurationManager.java:244) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConf gurationManager.java:223) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConf gurationManager.java:110) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f. nvoke(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) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor. ava:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$70fe5f97 loadConfiguration(generated) at org.apache.geronimo.console.car.ResultsHandler.actionAfterView(ResultsHandler.java:75) at
Re: Running jsp-examples plugin
Was this with the Tomcat/J2EE version of Geronimo? Thanks, Aaron On 4/27/06, anita kulshreshtha [EMAIL PROTECTED] wrote: I ran the following test with today's build : 1. From console click plugins -- Search Plugins -- Jakarta JSP Examples -- install plugin -- start g/jsp-examples../car 2. Web App Wars -- stop -- uninstall (jsp-examples) 3. repeat 1. After clicking on 'plugins' the warnings are printed. The car is installed and started successfully and works. an error occurs in step2. The stack trace appears during 'start ' in step 3. Thanks Anita Web Applications: http://a-680de82293e44:8080/ http://a-680de82293e44:8080/console http://a-680de82293e44:8080/console-standard http://a-680de82293e44:8080/remote-deploy Geronimo Application Server started 10:08:38,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb AppContext in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplicatio n=null,j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 10:08:38,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon text in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null ,j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 10:08:38,656 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb AppContext in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null ,j2eeType=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 10:08:38,656 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon text in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeT ype=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 10:09:10,390 INFO [DownloadCARHandler] 10:09:10,890 INFO [DWRServlet] retrieved system configuration file: sun.net.www.protocol.jar.JarURL [EMAIL PROTECTED] 10:09:11,406 INFO [DownloadCARHandler] 10:09:11,406 INFO [DownloadCARHandler] Installation finished 10:12:06,968 ERROR [LocalAttributeManager] Trying to stop unknown configuration: geronimo/jsp-exampl es-tomcat/1.1-SNAPSHOT/car 0:14:29,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb ppContext in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplicatio =null,j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 0:14:29,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon ext in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 0:14:29,609 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb ppContext in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null j2eeType=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 0:14:29,609 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon ext in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeT pe=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 0:14:52,718 INFO [DownloadCARHandler] 0:14:53,718 INFO [DownloadCARHandler] 0:14:53,718 INFO [DownloadCARHandler] Installation finished 0:14:58,609 ERROR [ResultsHandler] Unable to start configuration geronimo/jsp-examples-tomcat/1.1-S APSHOT/car rg.apache.geronimo.kernel.config.LifecycleException: load of geronimo/jsp-examples-tomcat/1.1-SNAPS OT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConf gurationManager.java:244) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConf gurationManager.java:223) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConf gurationManager.java:110) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f. nvoke(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) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor. ava:96) at
[jira] Created: (GERONIMO-1925) JSP Example Plugin Install/Uninstall/Install doesn't work
JSP Example Plugin Install/Uninstall/Install doesn't work - Key: GERONIMO-1925 URL: http://issues.apache.org/jira/browse/GERONIMO-1925 Project: Geronimo Type: Bug Security: public (Regular issues) Components: Plugins Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1 From dev list: I ran the following test with today's build : 1. From console click plugins -- Search Plugins -- Jakarta JSP Examples -- install plugin -- start g/jsp-examples../car 2. Web App Wars -- stop -- uninstall (jsp-examples) 3. repeat 1. After clicking on 'plugins' the warnings are printed. The car is installed and started successfully and works. an error occurs in step2. The stack trace appears during 'start ' in step 3. -- 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-1925) JSP Example Plugin Install/Uninstall/Install doesn't work
[ http://issues.apache.org/jira/browse/GERONIMO-1925?page=all ] Aaron Mulder updated GERONIMO-1925: --- Assign To: Aaron Mulder Priority: Critical (was: Major) JSP Example Plugin Install/Uninstall/Install doesn't work - Key: GERONIMO-1925 URL: http://issues.apache.org/jira/browse/GERONIMO-1925 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Plugins Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 From dev list: I ran the following test with today's build : 1. From console click plugins -- Search Plugins -- Jakarta JSP Examples -- install plugin -- start g/jsp-examples../car 2. Web App Wars -- stop -- uninstall (jsp-examples) 3. repeat 1. After clicking on 'plugins' the warnings are printed. The car is installed and started successfully and works. an error occurs in step2. The stack trace appears during 'start ' in step 3. -- 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-1922) Plugin Export should check for shared libs
[ http://issues.apache.org/jira/browse/GERONIMO-1922?page=all ] Aaron Mulder updated GERONIMO-1922: --- Assign To: Aaron Mulder Priority: Critical (was: Major) Plugin Export should check for shared libs -- Key: GERONIMO-1922 URL: http://issues.apache.org/jira/browse/GERONIMO-1922 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 The export process should check configation.findGBeans(new AbstractNameQuery(SharedLib.class.getName()) -- 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-1892) Make JMS Provider Properties a GBean
[ http://issues.apache.org/jira/browse/GERONIMO-1892?page=all ] Aaron Mulder updated GERONIMO-1892: --- Assign To: Aaron Mulder Priority: Minor (was: Major) Make JMS Provider Properties a GBean Key: GERONIMO-1892 URL: http://issues.apache.org/jira/browse/GERONIMO-1892 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Minor Fix For: 1.1 It would be great to declare an interface and GBean for the JMS provider properties. Then the portlet could look up all matching GBeans by interface. So, if you want to add another JMS provider, you just include that GBean in your JMS server module and it's immediately available in the console. -- 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-1888) Better help for bad references
[ http://issues.apache.org/jira/browse/GERONIMO-1888?page=all ] Aaron Mulder updated GERONIMO-1888: --- Assign To: Aaron Mulder Priority: Minor (was: Major) Better help for bad references -- Key: GERONIMO-1888 URL: http://issues.apache.org/jira/browse/GERONIMO-1888 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: usability Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Minor Fix For: 1.1 If a GBean can't start beacuse of a missing reference, it would be great to give a more helpful error message. Like if the reference included the name Foo, print a list of all AbstractNames including name=Foo in the format you'd expect for the reference in question (slightly different for GBean-to-GBean references vs J2EE Component-to-Resource references, etc.). It would be great if it came out like this: Unable to resolve reference to artifactIdbar/artifactIdnameFoo/name. Did you mean one of these instead? * artifactIdbaz/artifactIdnameFoo/name * artifactIdother/artifactIdnameFoo/name Unable to resolve reference to artifactIdbar/artifactIdnameFoo/name. There are no components with nameFoo/name in this module or any of its dependencies. Perhaps you need to add a dependency to this module and point it to one of the following modules which has a component with nameFoo/name: * mygroup/myartifact/1.0/car * other/something/3.4/rar This is aggravated by the fact that our resource target names are no longer JMX names, so we can't tell people to look up the component in the JMX debug tool. However, it's mitigated by the fact that you have to declare dependencies explicitly and can more often just use nameFoo/name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1873) Deployment must handle dynamically-registered module builders
[ http://issues.apache.org/jira/browse/GERONIMO-1873?page=all ] Aaron Mulder reassigned GERONIMO-1873: -- Assign To: Aaron Mulder Deployment must handle dynamically-registered module builders - Key: GERONIMO-1873 URL: http://issues.apache.org/jira/browse/GERONIMO-1873 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Currently the deployment infrastructure does some things specific to different module types -- like identifying the embedded deployment plan in a xAR so it can look up the config ID, and searching for child modules of an EAR. This is currently hardcoded to the specific set of module types supported by Geronimo by default. It should be able to handle builders deployed later (e.g. Spring, ServiceMix, whatever), which probably means it needs to be able to ask something on the server-side what modules are available, what their nested plan files are called, and what their j2eeType would be. -- 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-1829) Service Plans should allow GBean references by interface (vs. by name)
[ http://issues.apache.org/jira/browse/GERONIMO-1829?page=comments#action_12376739 ] Aaron Mulder commented on GERONIMO-1829: There's kind of a workaround in 1.1 where you declare the reference type in GBeanInfo and then specify no query parameters in the plan. Service Plans should allow GBean references by interface (vs. by name) -- Key: GERONIMO-1829 URL: http://issues.apache.org/jira/browse/GERONIMO-1829 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: kernel Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.2 -- 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-1902) Console does not allow editing of Tomcat Connector Attributes
[ http://issues.apache.org/jira/browse/GERONIMO-1902?page=comments#action_12376741 ] Paul McMahan commented on GERONIMO-1902: The functional problem is that clicking on the edit link in the connector portlet seems to have no result; it just redisplays the list of connectors. There's no stack trace because ultimately what ends up happening is that the connector selected by the operator is not found because it's not looked up correctly and the portlet just reverts back to the default view. A patch attached to GERONIMO-1802 (webserver-listeners.patch) fixes the problem. Console does not allow editing of Tomcat Connector Attributes - Key: GERONIMO-1902 URL: http://issues.apache.org/jira/browse/GERONIMO-1902 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Environment: All Reporter: Matt Hogstrom Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 When attempting to edit the Tomcat Connectors the following messages are generated: 08:56:26,315 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 08:56:26,318 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 08:56:26,566 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 08:56:26,587 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer 08:56:26,593 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatManagerImpl in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebManager -- 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-1819) Port SQL realm fix from 1.1 to HEAD
[ http://issues.apache.org/jira/browse/GERONIMO-1819?page=all ] Aaron Mulder closed GERONIMO-1819: -- Resolution: Invalid If we listed all the changes that have to go from 1.1 to HEAD in JIRA we'd go insane Port SQL realm fix from 1.1 to HEAD --- Key: GERONIMO-1819 URL: http://issues.apache.org/jira/browse/GERONIMO-1819 Project: Geronimo Type: Bug Security: public(Regular issues) Components: security, console Versions: 1.2 Reporter: Aaron Mulder Fix For: 1.2 The commit 392443 included the fix to GERONIMO-1789 plus some other stuff. The changes to KernelManagementHelper and SecurityRealmPortlet.loadModule need to be ported to HEAD. Not sure if this will be done during the great 1.1 to HEAD merge or should be done separately. -- 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-1704) Console security realm doesn't let you pick a JAR
[ http://issues.apache.org/jira/browse/GERONIMO-1704?page=all ] Aaron Mulder updated GERONIMO-1704: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) Console security realm doesn't let you pick a JAR - Key: GERONIMO-1704 URL: http://issues.apache.org/jira/browse/GERONIMO-1704 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console, security Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 It's not possible to use the console to deploy a custom login module because we don't let you specify a JAR that holds the login module and principal classes! -- 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-1695) CORBA for EJB with Local interface only causes NPE
[ http://issues.apache.org/jira/browse/GERONIMO-1695?page=all ] Aaron Mulder updated GERONIMO-1695: --- Fix Version: 1.1 1.2 Version: 1.0 Assign To: Aaron Mulder Priority: Critical (was: Major) Should verify the fix is in OpenEJB for G1.1 and then take 1.1 off the fix version list and leave this to be checked in 1.2/HEAD after the EJB refactoring. CORBA for EJB with Local interface only causes NPE -- Key: GERONIMO-1695 URL: http://issues.apache.org/jira/browse/GERONIMO-1695 Project: Geronimo Type: Bug Security: public(Regular issues) Components: CORBA Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1, 1.2 I have an EJB with a local interface and I tried applying CORBA settings. It blows up during deployment. My guess is that it wants a remote interface to be there, but somehow, the checks in StandardServant:126 are not working and the interface just comes up as null. Caused by: java.lang.NullPointerException at org.openejb.corba.util.Util.getAllInterfaces(Util.java:593) at org.openejb.corba.util.Util.getAllMethods(Util.java:815) at org.openejb.corba.util.Util.iiopMap(Util.java:608) at org.openejb.corba.util.Util.mapOperationToMethod(Util.java:604) at org.openejb.corba.StandardServant.init(StandardServant.java:135) at org.openejb.corba.StandardServant.init(StandardServant.java:116) at org.openejb.corba.Adapter.init(Adapter.java:100) ... 67 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1691) Console should help configure Geronimo to hook up to Apache HTTP
[ http://issues.apache.org/jira/browse/GERONIMO-1691?page=all ] Aaron Mulder resolved GERONIMO-1691: Resolution: Fixed Assign To: Aaron Mulder Console should help configure Geronimo to hook up to Apache HTTP Key: GERONIMO-1691 URL: http://issues.apache.org/jira/browse/GERONIMO-1691 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console, web Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 1.1 There are a number of steps involved in hooking Geronimo up to Apache HTTP via mod_jk -- getting the module installed, writing a workers.properties, and adding configuration information to the Apache config file (including some for each web application to be exposed). It would be nice if the console could walk you through this. -- 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-1691) Console should help configure Geronimo to hook up to Apache HTTP
[ http://issues.apache.org/jira/browse/GERONIMO-1691?page=all ] Aaron Mulder updated GERONIMO-1691: --- Fix Version: 1.1 (was: 1.2) Console should help configure Geronimo to hook up to Apache HTTP Key: GERONIMO-1691 URL: http://issues.apache.org/jira/browse/GERONIMO-1691 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console, web Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 1.1 There are a number of steps involved in hooking Geronimo up to Apache HTTP via mod_jk -- getting the module installed, writing a workers.properties, and adding configuration information to the Apache config file (including some for each web application to be exposed). It would be nice if the console could walk you through this. -- 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-1687) NPE during deployment related to EJB Ref
[ http://issues.apache.org/jira/browse/GERONIMO-1687?page=all ] Aaron Mulder updated GERONIMO-1687: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) NPE during deployment related to EJB Ref Key: GERONIMO-1687 URL: http://issues.apache.org/jira/browse/GERONIMO-1687 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, naming Versions: 1.0 Environment: Geronimo 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 In my case this was caused by an EAR containing an EJB JAR and WAR but only the WAR was listed in application.xml. Clearly a user error, but obviously we should have an error message not an NPE. 15:45:22,432 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.j2ee.deployment.RefContext.getEJBLocalRef(RefContext.java:111) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.addEJBLocalRefs(ENCConfigBuilder.java:507) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponentContext(ENCConfigBuilder.java:781) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildComponentContext(JettyModuleBuilder.java:1291) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:464) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder$$FastClassByCGLIB$$b30bba8a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:160) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at
[jira] Updated: (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 updated GERONIMO-1684: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder 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
[jira] Updated: (GERONIMO-1683) Web app context-root should trim whitespace
[ http://issues.apache.org/jira/browse/GERONIMO-1683?page=all ] Aaron Mulder updated GERONIMO-1683: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) 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 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] Updated: (GERONIMO-1680) MDB without activation-config in openejb-jar.xml silently fails
[ http://issues.apache.org/jira/browse/GERONIMO-1680?page=all ] Aaron Mulder updated GERONIMO-1680: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) 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: OpenEJB, ActiveMQ 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] Updated: (GERONIMO-1642) Deployment plan namespace validation
[ http://issues.apache.org/jira/browse/GERONIMO-1642?page=all ] Aaron Mulder updated GERONIMO-1642: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) Deployment plan namespace validation Key: GERONIMO-1642 URL: http://issues.apache.org/jira/browse/GERONIMO-1642 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment, OpenEJB, web Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 When you deploy with a geronimo deployment plan packaged in the archive, but it has the wrong namespace, the file is ignored. If anything, you get a message saying the plan is required, or that the archive is not a WAR/JAR/etc. We should have special detection for geronimo-application.xml, geronimo-ra.xml, geronimo-web.xml, and openejb-jar.xml that notices if the file is present but has the wrong namespace, and prints a suggestive WARN or ERROR message to the console. Probably for the application.xml, web.xml, ra.xml, and ejb-jar.xml too. People have asked for help on the mailing list several times recently when they had this (bad namespace) 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: Help!!! Problems using KernelManagementHelper got from getRemoteKernelManager()
This class was rewritten so that is only works with a local kernel. Rewriting it for a local kernel vastly simplified the code and make is more accessible for new users to help with the console, and it is expected that the for the near future the console will always be local. If you need these features from a remote client, I suggest you first take a look at what is available via a standard remote JMX connection. You can browse the MBeanServer using jconsole in Java5. In the future, when we need a to access the kernel remotely for the kernel, I expect us to use a remote pojo technology like lingo.codehaus.org. -dain On Apr 27, 2006, at 12:08 AM, Vamsavardhana Reddy wrote: Hi Aron, The code chunk from my first e-mail runs fine with G1.0 . Some of the recent changes might have broken the KernelDelegate. I will try to create a test client and post it to the dev-list. Thanks, Vamsi On 4/25/06, Aaron Mulder [EMAIL PROTECTED] wrote: Well, maybe I spoke too soon. After thinking more about it, I guess there are two options: 1) Create your own GBean to run on the server side, where your client gives simple commands and the GBean does all the work interfacing with the server components, so that there's no serialization involved to return a J2EEServer, etc. 2) It may be that it's not as hard as I'm imagining to convert GBean arguments and return types to AbstractNames and vice versa in the server and the proxies. Can you post a simple test client that gets the servers from a domain or whatever and curently blows up? That would make it easier to evaluate this kind of change. Thanks, Aaron On 4/25/06, Aaron Mulder [EMAIL PROTECTED] wrote: I don't think there's going to be a fix for 1.1 -- if a method returns a GBean we don't have a way to serialize it to the client. For 1.2 I think we can work some magic in the proxies, and/or switch to a different protocol altogether. Thanks, Aaron On 4/25/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I am running the following piece of code. KernelManagementHelper mgr = KernelManagementHelper.getRemoteKernelManager (localhost, system, manager); J2EEDomain domain = mgr.getDomains()[0]; String[] servers = domain.getServers(); System.out.println(servers[0]); J2EEServer[] j2eeServers = domain.getServerInstances(); System.out.println(j2eeServers[0]); domain.getServers() runs fine, whereas, domain.getServerInstances() throws an exception. Please suggest a fix or a workaround for this problem. -Vamsi -- java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.geronimo.management.geronimo.J2EEServer$ $EnhancerByCGLIB$$d620c0d0 at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:207) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientUnmarshaller.chain (ClientUnmarshaller.java:65) at mx4j.remote.rmi.ClientUnmarshaller.invoke (ClientUnmarshaller.java:54) at $Proxy0.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientExceptionCatcher.invoke (ClientExceptionCatcher.java:40) at $Proxy0.invoke(Unknown Source) at org.apache.geronimo.system.jmx.KernelDelegate.invokeKernel (KernelDelegate.java:880) at org.apache.geronimo.system.jmx.KernelDelegate.getAttribute (KernelDelegate.java :485) at org.apache.geronimo.kernel.basic.KernelGetAttributeInvoker.invoke (KernelGetAttributeInvoker.java:36) at org.apache.geronimo.system.jmx.JMXProxyMethodInterceptor.intercept (JMXProxyMethodInterceptor.java:89) at org.apache.geronimo.management.geronimo.J2EEDomain$ $EnhancerByCGLIB$$45e3ccef.getServerInstances(generated) at PeekRemoteKernel.main (PeekRemoteKernel.java:19) Caused by: java.io.WriteAbortedException: writing aborted;
Re: Help!!! Problems using KernelManagementHelper got from getRemoteKernelManager()
Though I think KMH is a red herring here. It sounds like the actual goal is to e.g. get a J2EEServer from a J2EEDomain. Before, you could have KMH do this for you. Now, J2EEDomain can do it directly, but fails to work remotely. I'm thinking we could put a little bit of code in to convert service references to AbstractNames and vice versa for the remote kernel caller. I'm going to see if this turns out to be easy or not. I first thought not, but now I think it might be easy. Thanks, Aaron On 4/27/06, Dain Sundstrom [EMAIL PROTECTED] wrote: This class was rewritten so that is only works with a local kernel. Rewriting it for a local kernel vastly simplified the code and make is more accessible for new users to help with the console, and it is expected that the for the near future the console will always be local. If you need these features from a remote client, I suggest you first take a look at what is available via a standard remote JMX connection. You can browse the MBeanServer using jconsole in Java5. In the future, when we need a to access the kernel remotely for the kernel, I expect us to use a remote pojo technology like lingo.codehaus.org. -dain On Apr 27, 2006, at 12:08 AM, Vamsavardhana Reddy wrote: Hi Aron, The code chunk from my first e-mail runs fine with G1.0 . Some of the recent changes might have broken the KernelDelegate. I will try to create a test client and post it to the dev-list. Thanks, Vamsi On 4/25/06, Aaron Mulder [EMAIL PROTECTED] wrote: Well, maybe I spoke too soon. After thinking more about it, I guess there are two options: 1) Create your own GBean to run on the server side, where your client gives simple commands and the GBean does all the work interfacing with the server components, so that there's no serialization involved to return a J2EEServer, etc. 2) It may be that it's not as hard as I'm imagining to convert GBean arguments and return types to AbstractNames and vice versa in the server and the proxies. Can you post a simple test client that gets the servers from a domain or whatever and curently blows up? That would make it easier to evaluate this kind of change. Thanks, Aaron On 4/25/06, Aaron Mulder [EMAIL PROTECTED] wrote: I don't think there's going to be a fix for 1.1 -- if a method returns a GBean we don't have a way to serialize it to the client. For 1.2 I think we can work some magic in the proxies, and/or switch to a different protocol altogether. Thanks, Aaron On 4/25/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi, I am running the following piece of code. KernelManagementHelper mgr = KernelManagementHelper.getRemoteKernelManager (localhost, system, manager); J2EEDomain domain = mgr.getDomains()[0]; String[] servers = domain.getServers(); System.out.println(servers[0]); J2EEServer[] j2eeServers = domain.getServerInstances(); System.out.println(j2eeServers[0]); domain.getServers() runs fine, whereas, domain.getServerInstances() throws an exception. Please suggest a fix or a workaround for this problem. -Vamsi -- java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.geronimo.management.geronimo.J2EEServer$ $EnhancerByCGLIB$$d620c0d0 at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:207) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientUnmarshaller.chain (ClientUnmarshaller.java:65) at mx4j.remote.rmi.ClientUnmarshaller.invoke (ClientUnmarshaller.java:54) at $Proxy0.invoke(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientExceptionCatcher.invoke (ClientExceptionCatcher.java:40) at $Proxy0.invoke(Unknown
[jira] Created: (SM-414) SourceTransformer cant transf orm to DOM with non US ASCI I characters like 'ä' or 'ü'
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
Priority: Blocker
Fix For: 3.0, incubation
Attachments: SourceTransformer-sources.zip
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
Re: Running jsp-examples plugin
yes, j2ee-tomcat-server. Thanks Anita --- Aaron Mulder [EMAIL PROTECTED] wrote: Was this with the Tomcat/J2EE version of Geronimo? Thanks, Aaron On 4/27/06, anita kulshreshtha [EMAIL PROTECTED] wrote: I ran the following test with today's build : 1. From console click plugins -- Search Plugins -- Jakarta JSP Examples -- install plugin -- start g/jsp-examples../car 2. Web App Wars -- stop -- uninstall (jsp-examples) 3. repeat 1. After clicking on 'plugins' the warnings are printed. The car is installed and started successfully and works. an error occurs in step2. The stack trace appears during 'start ' in step 3. Thanks Anita Web Applications: http://a-680de82293e44:8080/ http://a-680de82293e44:8080/console http://a-680de82293e44:8080/console-standard http://a-680de82293e44:8080/remote-deploy Geronimo Application Server started 10:08:38,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb AppContext in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplicatio n=null,j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 10:08:38,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon text in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null ,j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 10:08:38,656 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb AppContext in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null ,j2eeType=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 10:08:38,656 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon text in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeT ype=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 10:09:10,390 INFO [DownloadCARHandler] 10:09:10,890 INFO [DWRServlet] retrieved system configuration file: sun.net.www.protocol.jar.JarURL [EMAIL PROTECTED] 10:09:11,406 INFO [DownloadCARHandler] 10:09:11,406 INFO [DownloadCARHandler] Installation finished 10:12:06,968 ERROR [LocalAttributeManager] Trying to stop unknown configuration: geronimo/jsp-exampl es-tomcat/1.1-SNAPSHOT/car 0:14:29,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb ppContext in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplicatio =null,j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 0:14:29,562 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon ext in provided ClassLoader for geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null j2eeType=WebModule,name=geronimo/remote-deploy-tomcat/1.1-SNAPSHOT/car 0:14:29,609 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWeb ppContext in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null j2eeType=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 0:14:29,609 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatCon ext in provided ClassLoader for geronimo/welcome-tomcat/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeT pe=WebModule,name=geronimo/welcome-tomcat/1.1-SNAPSHOT/car 0:14:52,718 INFO [DownloadCARHandler] 0:14:53,718 INFO [DownloadCARHandler] 0:14:53,718 INFO [DownloadCARHandler] Installation finished 0:14:58,609 ERROR [ResultsHandler] Unable to start configuration geronimo/jsp-examples-tomcat/1.1-S APSHOT/car rg.apache.geronimo.kernel.config.LifecycleException: load of geronimo/jsp-examples-tomcat/1.1-SNAPS OT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConf gurationManager.java:244) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConf gurationManager.java:223) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConf gurationManager.java:110) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f. nvoke(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) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at
[jira] Created: (GERONIMO-1926) Changes to navigation break remote clients
Changes to navigation break remote clients
--
Key: GERONIMO-1926
URL: http://issues.apache.org/jira/browse/GERONIMO-1926
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: core
Versions: 1.1
Reporter: Aaron Mulder
Assigned to: Aaron Mulder
Priority: Critical
Fix For: 1.1
Attachments: peek-remote.jar, peek.jar
From an e-mail:
I have created a simple program that calls J2EEDomain.getServerInstances() on
J2EEDomain obtained from remote kernel. Detatch the two jars to bin directory
and run the program using the cmd java -jar peek.jar. Here is the code in
the main() method.
public static void main(String[] args) throws Exception {
String host = localhost;
String username = system;
String password = manager;
for(int i = 0; i args.length-1; ++i) {
if(--username.equalsIgnoreCase(args[i])) username = args[i+1];
if(--host.equalsIgnoreCase(args[i])) host = args[i+1];
if(--password.equalsIgnoreCase(args[i])) password = args[i+1];
}
System.out.println(Using host=+host+, username=+username+,
password=+password);
KernelManagementHelper mgr =
KernelManagementHelper.getRemoteKernelManager(host, username, password);
System.out.println(KernelManagementHelper = +mgr);
J2EEDomain domain = mgr.getDomains()[0];
System.out.println(J2EEDomain = +domain);
J2EEServer[] j2eeServers = domain.getServerInstances();
System.out.println(J2EEServer = +j2eeServers[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-1926) Changes to navigation break remote clients
[ http://issues.apache.org/jira/browse/GERONIMO-1926?page=all ]
Aaron Mulder updated GERONIMO-1926:
---
Attachment: peek-remote.jar
peek.jar
Changes to navigation break remote clients
--
Key: GERONIMO-1926
URL: http://issues.apache.org/jira/browse/GERONIMO-1926
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: core
Versions: 1.1
Reporter: Aaron Mulder
Assignee: Aaron Mulder
Priority: Critical
Fix For: 1.1
Attachments: peek-remote.jar, peek.jar
From an e-mail:
I have created a simple program that calls J2EEDomain.getServerInstances() on
J2EEDomain obtained from remote kernel. Detatch the two jars to bin
directory and run the program using the cmd java -jar peek.jar. Here is
the code in the main() method.
public static void main(String[] args) throws Exception {
String host = localhost;
String username = system;
String password = manager;
for(int i = 0; i args.length-1; ++i) {
if(--username.equalsIgnoreCase(args[i])) username = args[i+1];
if(--host.equalsIgnoreCase(args[i])) host = args[i+1];
if(--password.equalsIgnoreCase(args[i])) password = args[i+1];
}
System.out.println(Using host=+host+, username=+username+,
password=+password);
KernelManagementHelper mgr =
KernelManagementHelper.getRemoteKernelManager(host, username, password);
System.out.println(KernelManagementHelper = +mgr);
J2EEDomain domain = mgr.getDomains()[0];
System.out.println(J2EEDomain = +domain);
J2EEServer[] j2eeServers = domain.getServerInstances();
System.out.println(J2EEServer = +j2eeServers[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
Re: Implementing Global JNDI
I think we need to provide a non-persistent r/w global jndi tree since there are so many apps that depend on it. In addition, I think we need a way for users to provide a set of bindings (JNDI, cos- naming, jaxr... really anything) to EJBs, RAs, and any GBean so that the services they need are available where their application expect. I have been thinking about the binding problem for a while and just haven't had time to work on it myself. I think we can do something as simple as this for most services: gbean name=foo-binding class=org.apache.geronimo.naming.JndiBinding reference name=objectnamemyService/... attribute name=addressservices/myService/... /... For J2EE services we want to bind, I think the xml above is way to complex and we need to provide some syntactic sugar. -dain On Apr 27, 2006, at 1:22 AM, David Jencks wrote: I'm not convinced this discussion has got to the hard parts yet :-) I hope there turn out not to be any :-) Please don't change stuff in the read-only java:comp/env context since it is pretty much completely specified by the spec. Note also that according to the spec a j2ee compliant app will only use this jndi context, and only use the entries defined in the j2ee deployment descriptors. I think you can use a lot of the jndi infrastructure we already have including the geronimo context and the references to jca connection factories, ejbs, etc. The missing part is how to get these references bound into your context. One approach is to write gbeans that install a reference when started and remove it when stopped. I would start by just including these as plain gbeans in plans, and once that works consider modifying the builders to add them automatically based on xml in the geronimo plans. An alternative might be to investigating using say Directory to persist the references directly. I don't know enough about ldap to know if this makes any sense at all. thanks david jencks On Apr 26, 2006, at 11:56 PM, Manu George wrote: Comments inline On 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Looking more closely, it seems I was wrong. Gbeans with a j2eeType=JCAManagedConnectionFactory have a connectionFactoryInterface attribute that gives the name of the main interface to use when binding the object to the JNDI context. For EJB, GBeans with a j2eeType=StatelessSessionBean (or EntityBean ...) have attributes for the home and business interfaces. So i guess it should be ok. great Another way to handle that would be to bind the resource to the global JNDI tree when the resource is created: each configuration would contain a list of gbeans to bind in the jndi tree when the configuration is loaded. Else, we will need some listener to listen to gbeans creation / destruction so that we can bind / unbind them from the global jndi context. Binding the resource during creation seems to be the simpler way. But what about the next time the server starts up. How is the context initialised? Do we populate during startup of each resource or application again or is persistence used in some way? In the case of listeners the above problem won't arise. A few questions: * I' m wondering how the global JNDI context will coexist with the existing ENC context, especially if the global jndi context is read-write ... Maybe there is no need for a local jndi context ... Yes that is a question i also have :-) . The local jndi context allows us to have app specific contexts and this has some advantages. A global jndi also has some advantages. Probably by default we can use the local context and if the user specifies a custom factory the global one or vice versa. * what is the purpose of the jndiname property ? If this is the key for a gbean in the jndi tree, I thought we could use the name attribute of the gbean: jdbc/TradeDataSource , jms/QueueConnectionFactory. These names can also be TradeDatasource so then we may need to add jdbc and if jdbc is there in the name as you mentioned do we need to add jdbc to the name or not. These are a few issues which made me propose the jndiName property . * what about conflicting names for JCA resources... currently there is nothing to prevent deploying JCA resource (or other resources that would be bound to jndi) with the same name I think deployment should fail with an resource already bound exception. Not sure if this or any other validation is implemented for the local context. Thanks Manu
[jira] Updated: (GERONIMO-1592) Add NamedUPCredentialLoginModule to Console Realm Wizard
[ http://issues.apache.org/jira/browse/GERONIMO-1592?page=all ] Aaron Mulder updated GERONIMO-1592: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) Add NamedUPCredentialLoginModule to Console Realm Wizard Key: GERONIMO-1592 URL: http://issues.apache.org/jira/browse/GERONIMO-1592 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console, security, webservices Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 The console currently has a checkbox to store credentials (using the GeronimoPasswordCredentialLoginModule). It should likewise have a checkbox and text field to store credentials using the NamedUPCredentialLoginModule (where the text field specifies the name to save under). -- 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-1586) In naming schema, make uri optional in portType
[ http://issues.apache.org/jira/browse/GERONIMO-1586?page=all ] Aaron Mulder updated GERONIMO-1586: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Minor (was: Major) Would like to look at this for 1.1, but seriously, who uses J2EE web services anyway? Much less with partial WSDLs. Should at least see if it's still an issue in the 1.1 schemas. In naming schema, make uri optional in portType --- Key: GERONIMO-1586 URL: http://issues.apache.org/jira/browse/GERONIMO-1586 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: naming, webservices Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Minor Fix For: 1.1 Currently the portType requires uri. If you only want to add security settings to the web service, and are happy to default to the URI in the WSDL, you should not need to repeat the URI here. So technically, you should need either the uri or credentials-name or both, but I think it's easier to model in the schema as making them both optional, and if you add a port with nothing but a name, well then, nothing will change from the original J2EE DD service-ref and WSDL. -- 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: (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 ]
Juergen Mayrbaeurl updated SM-414:
--
Attachment: SampleInMessage.xml
Sample In Message with non US-ASCII characters
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
Priority: Blocker
Fix For: 3.0, incubation
Attachments: SampleInMessage.xml, SourceTransformer-sources.zip
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] Updated: (GERONIMO-1585) Web app security on /* causes deployment exception
[ http://issues.apache.org/jira/browse/GERONIMO-1585?page=all ] Aaron Mulder updated GERONIMO-1585: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: http://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Type: Bug Security: public(Regular issues) Components: web, security Versions: 1.0 Environment: Geronimo 1.0 with Jetty and tomcat Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Attachments: security.patch Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- 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-1582) NPE for EJB webservices.xml with bad jaxrpc-mapping-file
[ http://issues.apache.org/jira/browse/GERONIMO-1582?page=all ] Aaron Mulder updated GERONIMO-1582: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) NPE for EJB webservices.xml with bad jaxrpc-mapping-file -- Key: GERONIMO-1582 URL: http://issues.apache.org/jira/browse/GERONIMO-1582 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 If the jaxrpc-mapping-file points to an invalid location, a NullPointerException is produced. It should instead give a DeploymentException with a message like: webservices.xml for EJB JAR points to jaxrpc-mapping-file 'META-INF/foo.map' for service 'bar' but that file is not found. 11:47:01,051 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.deployment.util.NestedJarFile.getInputStream(NestedJarFile.java:187) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:95) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:88) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:315) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor(generated) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at
[jira] Updated: (GERONIMO-1581) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with /
[ http://issues.apache.org/jira/browse/GERONIMO-1581?page=all ] Aaron Mulder updated GERONIMO-1581: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with / --- Key: GERONIMO-1581 URL: http://issues.apache.org/jira/browse/GERONIMO-1581 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 It seems like it ought to be legal for the wsdl-file value to start with a / (in fact, the book I got my example from uses that). However, in Geronimo, that results in a java.lang.RuntimeException: Could not open stream to wsdl file. If we can't handle the preceding /, we should probably just strip it if it's there and then go on as normal (without the leading / everything is fine). The same appears to be true for the jaxrpc-mapping-file though it produces an NPE instead of the RuntimeException. -- 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
JBI BOF at JavaOne
Hi ServiceMixers! In case you didn't already know, there is going to be a BOF session at this year's JavaOne entitled What's Next For JBI?: https://www28.cplan.com/javaone06_cv_124_1/session_details.jsp?isid=2780 89ilocation_id=124-1ilanguage=english The JBI spec leads as well as myself and Dave Chappell (both EG members) will be facilitating discussion and taking notes, but it's all about open discussion. We'd really love if as many of the ServiceMix dev community could be there as possible - you guys are definitely on the cutting edge of actual JBI adoption/usage, and it would be great if you could join the conversation and share your opinions. Please consider attending what should be a fun event. Thanks, --Glen
[jira] Commented: (GERONIMO-1926) Changes to navigation break remote clients
[
http://issues.apache.org/jira/browse/GERONIMO-1926?page=comments#action_12376755
]
Aaron Mulder commented on GERONIMO-1926:
dain suggests:
public class GBeanProxyToken implements Serializable {
private static final long serialVersionUID = 2795647533801535900L;
private final AbstractName name;
public GBeanProxyToken(AbstractName name) {
this.name = name;
}
protected Object readResolve() {
Kernel kernel = getKernelFromThreadLocal();
ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
Object proxy = kernel.getProxyManager().createProxy(name,
classLoader);
return proxy;
}
}
Changes to navigation break remote clients
--
Key: GERONIMO-1926
URL: http://issues.apache.org/jira/browse/GERONIMO-1926
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: core
Versions: 1.1
Reporter: Aaron Mulder
Assignee: Aaron Mulder
Priority: Critical
Fix For: 1.1
Attachments: peek-remote.jar, peek.jar
From an e-mail:
I have created a simple program that calls J2EEDomain.getServerInstances() on
J2EEDomain obtained from remote kernel. Detatch the two jars to bin
directory and run the program using the cmd java -jar peek.jar. Here is
the code in the main() method.
public static void main(String[] args) throws Exception {
String host = localhost;
String username = system;
String password = manager;
for(int i = 0; i args.length-1; ++i) {
if(--username.equalsIgnoreCase(args[i])) username = args[i+1];
if(--host.equalsIgnoreCase(args[i])) host = args[i+1];
if(--password.equalsIgnoreCase(args[i])) password = args[i+1];
}
System.out.println(Using host=+host+, username=+username+,
password=+password);
KernelManagementHelper mgr =
KernelManagementHelper.getRemoteKernelManager(host, username, password);
System.out.println(KernelManagementHelper = +mgr);
J2EEDomain domain = mgr.getDomains()[0];
System.out.println(J2EEDomain = +domain);
J2EEServer[] j2eeServers = domain.getServerInstances();
System.out.println(J2EEServer = +j2eeServers[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] Created: (SM-415) Add a simple NamespaceContext implementation easily configurable from xbean
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 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
[jira] Updated: (GERONIMO-1580) Better error message for missing WSDL file for EJB web service
[ http://issues.apache.org/jira/browse/GERONIMO-1580?page=all ] Aaron Mulder updated GERONIMO-1580: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) Better error message for missing WSDL file for EJB web service -- Key: GERONIMO-1580 URL: http://issues.apache.org/jira/browse/GERONIMO-1580 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 If your webservices.xml file for a stateless session bean web service refers to a WSDL file that is not there, the error produced is java.lang.RuntimeException: Could not open stream to wsdl file It would be better if it produced a DeploymentException with a message something like: webservices.xml file for EJB JAR points to non-existant WSDL file 'META-INF/foo.wsdl' for service 'MyEJBWebService' The stack trace is 10:56:24,259 ERROR [Deployer] Deployment failed due to java.lang.RuntimeException: Could not open stream to wsdl file at org.apache.geronimo.axis.builder.SchemaInfoBuilder$JarWSDLLocator.getBaseInputSource(SchemaInfoBuilder.java:652) at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.readWsdl(SchemaInfoBuilder.java:555) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.init(SchemaInfoBuilder.java:141) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.init(SchemaInfoBuilder.java:125) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:312) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor(generated) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at
[jira] Updated: (GERONIMO-1579) NPE while deploying EJB as Web Service
[ http://issues.apache.org/jira/browse/GERONIMO-1579?page=all ] Aaron Mulder updated GERONIMO-1579: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) NPE while deploying EJB as Web Service -- Key: GERONIMO-1579 URL: http://issues.apache.org/jira/browse/GERONIMO-1579 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Surely caused by a coding/configuration error, but it would really be preferable to produce a better error message. 10:23:37,328 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.openejb.deployment.SessionBuilder.addWSContainerGBean(SessionBuilder.java:208) at org.openejb.deployment.SessionBuilder.buildBeans(SessionBuilder.java:187) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:527) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117) at mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219) at sun.reflect.GeneratedMethodAccessor265.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99) at
[jira] Updated: (GERONIMO-1510) NPE in connector DConfigBeans if no config params present on connection definition instance
[ http://issues.apache.org/jira/browse/GERONIMO-1510?page=all ] Aaron Mulder updated GERONIMO-1510: --- Fix Version: (was: 1.2) Assign To: Aaron Mulder Priority: Blocker (was: Major) NPE in connector DConfigBeans if no config params present on connection definition instance --- Key: GERONIMO-1510 URL: http://issues.apache.org/jira/browse/GERONIMO-1510 Project: Geronimo Type: Bug Security: public(Regular issues) Components: connector Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: dconfigbeans.patch, jms.rar Observed when loading a JMS plan that has no config params on the connection definition instance -- 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-1927) Need way to disable or make invisible security when using deployer.jar
Need way to disable or make invisible security when using deployer.jar -- Key: GERONIMO-1927 URL: http://issues.apache.org/jira/browse/GERONIMO-1927 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assigned to: Aaron Mulder Priority: Blocker Fix For: 1.1 We need a way to make the deployer security invisible to users. Proposal is to let them put .geronimo-deployer into their copy of deployer.jar, and have the code that looks for this file first search the classpath, then the users home directory. This will also let you have different logins for different servers. -- 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: Openwire C Client.
The consumer just hangs and does not seem to be receiving any messages. Does anyone else have a similar problem? consumer Connecting..OK Sending connect message.OK Reading Response. -- View this message in context: http://www.nabble.com/Openwire-C-Client.-t1506711.html#a4125129 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Updated: (GERONIMO-1492) Many org/apache/geronimo configIds still live in source tree
[ http://issues.apache.org/jira/browse/GERONIMO-1492?page=all ] Aaron Mulder updated GERONIMO-1492: --- Priority: Blocker (was: Major) It seems unlikely that this is the case, but we ought to run the grep all the same Many org/apache/geronimo configIds still live in source tree -- Key: GERONIMO-1492 URL: http://issues.apache.org/jira/browse/GERONIMO-1492 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.0 Reporter: Aaron Mulder Priority: Blocker Fix For: 1.1 I created a couple separate issues, but beyond those a quick search brought up a few more in magic G ball and day trader -- I stopped before it went any further, but we should grep for that and try to eliminate all the references to old-style config IDs. -- 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-1431) Make deploy tool and hot deploy directory work better together
[ http://issues.apache.org/jira/browse/GERONIMO-1431?page=all ] Aaron Mulder updated GERONIMO-1431: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) Make deploy tool and hot deploy directory work better together -- Key: GERONIMO-1431 URL: http://issues.apache.org/jira/browse/GERONIMO-1431 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment, Hot Deploy Dir Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Right now if you deploy something with the deploy tool and then drop an update in the hot deploy directory, it doesn't work. The hot deploy dir expects you to only use the hot dpeloy dir for that module. Likewise, if you deploy something with the hot deploy dir and then undeploy it with the deploy tool, it is not deleted from the hot deploy dir. Both of those can be fixed. -- 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-1421) DB portlet failure in Tomcat only
[ http://issues.apache.org/jira/browse/GERONIMO-1421?page=all ] Aaron Mulder updated GERONIMO-1421: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder Priority: Blocker (was: Major) Someone commented on either the Pluto or Tomcat issue that Tomcat definitely was not responsible for encoding and it was just a fluke that Jetty did it for you and it was clearly either Pluto or the end user that should do the encoding. I believe a workaround has been put in the portlet code; need to confirm for 1.1. DB portlet failure in Tomcat only - Key: GERONIMO-1421 URL: http://issues.apache.org/jira/browse/GERONIMO-1421 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console, Tomcat Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 - create a new database pool using the DB portlet - select the Derby Embedded type - pick the derby or derby-client JAR - give it a new or existing database name - add ;create=true to the end of the generated URL - click test This procedure works in the Jetty build but does not work in the Tomcat build. In Tomcat, it just redirects to the main screen for that portlet without any error message. The database is actually created (visible in the DB Manager portlet). This does not happen if you remove ;create=true from the URL and use an existing database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JBI BOF at JavaOne
On 4/27/06, Glen Daniels [EMAIL PROTECTED] wrote: Hi ServiceMixers! In case you didn't already know, there is going to be a BOF session at this year's JavaOne entitled What's Next For JBI?: https://www28.cplan.com/javaone06_cv_124_1/session_details.jsp?isid=2780 89ilocation_id=124-1ilanguage=english The JBI spec leads as well as myself and Dave Chappell (both EG members) will be facilitating discussion and taking notes, but it's all about open discussion. We'd really love if as many of the ServiceMix dev community could be there as possible - you guys are definitely on the cutting edge of actual JBI adoption/usage, and it would be great if you could join the conversation and share your opinions. Please consider attending what should be a fun event. Thanks for the note and URL, Glen! We're already planning on attending the BOF. See you guys in San Francisco next month ;-). 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] Created: (GERONIMO-1928) CLI doesn't allow --inPlace as an option
CLI doesn't allow --inPlace as an option Key: GERONIMO-1928 URL: http://issues.apache.org/jira/browse/GERONIMO-1928 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.1 The --inPlace argument is not accepted by the command line deployer. The following error is recieved: Error: No such command: '--inPlace' This option needs to be added to the syntax help as well. -- 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: (AMQ-695) Error when removing temp destinations (message on server console)
Error when removing temp destinations (message on server console) - Key: AMQ-695 URL: https://issues.apache.org/activemq/browse/AMQ-695 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.0 RC3 WARN Service - Failed to remove tmp destination temp-topic://ID:rfs8.lab.reconnex.net-34639-1146084114685-4:10:3 javax.jms.JMSException: Destination still has an active subscription: topic://ActiveMQ.Advisory.TempTopic at org.apache.activemq.broker.region.AbstractRegion.removeDestination(AbstractRegion.java:99) at org.apache.activemq.broker.region.RegionBroker.removeDestination(RegionBroker.java:222) at org.apache.activemq.broker.BrokerFilter.removeDestination(BrokerFilter.java:129) at org.apache.activemq.advisory.AdvisoryBroker.removeDestination(AdvisoryBroker.java:157) at org.apache.activemq.broker.BrokerFilter.removeDestination(BrokerFilter.java:129) at org.apache.activemq.broker.MutableBrokerFilter.removeDestination(MutableBrokerFilter.java:141) at org.apache.activemq.broker.AbstractConnection.processRemoveConnection(AbstractConnection.java:523) at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:59) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:196) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:93) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:70) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:114) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:139) at java.lang.Thread.run(Thread.java:595) WARN Service - Failed to remove tmp destination temp-topic://ID:rfs8.lab.reconnex.net-34639-1146084114685-4:10:4 javax.jms.JMSException: Destination still has an active subscription: topic://ActiveMQ.Advisory.TempTopic at org.apache.activemq.broker.region.AbstractRegion.removeDestination(AbstractRegion.java:99) at org.apache.activemq.broker.region.RegionBroker.removeDestination(RegionBroker.java:222) at org.apache.activemq.broker.BrokerFilter.removeDestination(BrokerFilter.java:129) at org.apache.activemq.advisory.AdvisoryBroker.removeDestination(AdvisoryBroker.java:157) at org.apache.activemq.broker.BrokerFilter.removeDestination(BrokerFilter.java:129) at org.apache.activemq.broker.MutableBrokerFilter.removeDestination(MutableBrokerFilter.java:141) at org.apache.activemq.broker.AbstractConnection.processRemoveConnection(AbstractConnection.java:523) at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:59) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:196) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:93) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:70) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:114) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:139) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-695) Error when removing temp destinations (message on server console)
[ https://issues.apache.org/activemq/browse/AMQ-695?page=comments#action_36102 ] Hiram Chirino commented on AMQ-695: --- Looks like a bug in the way that temporary destinations are being cleaned up. This should not affect you normal processing of messages. I will start working on a patch to fix this issue. The side-effect of this bug is that a little bit of memory will not be reclaimed every time a temporary destination is created and destroyed. If you have long lived temporary destinations, this may not be a big issue for you. Error when removing temp destinations (message on server console) - Key: AMQ-695 URL: https://issues.apache.org/activemq/browse/AMQ-695 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.0 RC3 WARN Service - Failed to remove tmp destination temp-topic://ID:rfs8.lab.reconnex.net-34639-1146084114685-4:10:3 javax.jms.JMSException: Destination still has an active subscription: topic://ActiveMQ.Advisory.TempTopic at org.apache.activemq.broker.region.AbstractRegion.removeDestination(AbstractRegion.java:99) at org.apache.activemq.broker.region.RegionBroker.removeDestination(RegionBroker.java:222) at org.apache.activemq.broker.BrokerFilter.removeDestination(BrokerFilter.java:129) at org.apache.activemq.advisory.AdvisoryBroker.removeDestination(AdvisoryBroker.java:157) at org.apache.activemq.broker.BrokerFilter.removeDestination(BrokerFilter.java:129) at org.apache.activemq.broker.MutableBrokerFilter.removeDestination(MutableBrokerFilter.java:141) at org.apache.activemq.broker.AbstractConnection.processRemoveConnection(AbstractConnection.java:523) at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:59) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:196) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:93) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:70) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:114) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:139) at java.lang.Thread.run(Thread.java:595) WARN Service - Failed to remove tmp destination temp-topic://ID:rfs8.lab.reconnex.net-34639-1146084114685-4:10:4 javax.jms.JMSException: Destination still has an active subscription: topic://ActiveMQ.Advisory.TempTopic at org.apache.activemq.broker.region.AbstractRegion.removeDestination(AbstractRegion.java:99) at org.apache.activemq.broker.region.RegionBroker.removeDestination(RegionBroker.java:222) at org.apache.activemq.broker.BrokerFilter.removeDestination(BrokerFilter.java:129) at org.apache.activemq.advisory.AdvisoryBroker.removeDestination(AdvisoryBroker.java:157) at org.apache.activemq.broker.BrokerFilter.removeDestination(BrokerFilter.java:129) at org.apache.activemq.broker.MutableBrokerFilter.removeDestination(MutableBrokerFilter.java:141) at org.apache.activemq.broker.AbstractConnection.processRemoveConnection(AbstractConnection.java:523) at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:59) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:196) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:93) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:70) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:114) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:139) at java.lang.Thread.run(Thread.java:595) -- 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: Openwire C Client.
Hey Sunil, Use the latest AMQ SNAPSHOT and consumer should work fine. There were updates to the STOMP protocol. Consumer uses these updates and AMQ RC2 was released before these changes. Good Luck! Vik -Original Message- From: srodrigues [mailto:[EMAIL PROTECTED] Sent: Thursday, April 27, 2006 12:54 PM To: activemq-dev@geronimo.apache.org Subject: RE: Openwire C Client. The consumer just hangs and does not seem to be receiving any messages. Does anyone else have a similar problem? consumer Connecting..OK Sending connect message.OK Reading Response. -- View this message in context: http://www.nabble.com/Openwire-C-Client.-t1506711.html#a4125129 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Implementing Global JNDI
On Apr 27, 2006, at 9:16 AM, Dain Sundstrom wrote: I think we need to provide a non-persistent r/w global jndi tree since there are so many apps that depend on it. In addition, I think we need a way for users to provide a set of bindings (JNDI, cos-naming, jaxr... really anything) to EJBs, RAs, and any GBean so that the services they need are available where their application expect. I have been thinking about the binding problem for a while and just haven't had time to work on it myself. I think we can do something as simple as this for most services: gbean name=foo-binding class=org.apache.geronimo.naming.JndiBinding reference name=objectnamemyService/... attribute name=addressservices/myService/... /... For J2EE services we want to bind, I think the xml above is way to complex and we need to provide some syntactic sugar. That's basically what I had in mind, but expressed more clearly and concretely thanks david jencks -dain On Apr 27, 2006, at 1:22 AM, David Jencks wrote: I'm not convinced this discussion has got to the hard parts yet :-) I hope there turn out not to be any :-) Please don't change stuff in the read-only java:comp/env context since it is pretty much completely specified by the spec. Note also that according to the spec a j2ee compliant app will only use this jndi context, and only use the entries defined in the j2ee deployment descriptors. I think you can use a lot of the jndi infrastructure we already have including the geronimo context and the references to jca connection factories, ejbs, etc. The missing part is how to get these references bound into your context. One approach is to write gbeans that install a reference when started and remove it when stopped. I would start by just including these as plain gbeans in plans, and once that works consider modifying the builders to add them automatically based on xml in the geronimo plans. An alternative might be to investigating using say Directory to persist the references directly. I don't know enough about ldap to know if this makes any sense at all. thanks david jencks On Apr 26, 2006, at 11:56 PM, Manu George wrote: Comments inline On 4/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Looking more closely, it seems I was wrong. Gbeans with a j2eeType=JCAManagedConnectionFactory have a connectionFactoryInterface attribute that gives the name of the main interface to use when binding the object to the JNDI context. For EJB, GBeans with a j2eeType=StatelessSessionBean (or EntityBean ...) have attributes for the home and business interfaces. So i guess it should be ok. great Another way to handle that would be to bind the resource to the global JNDI tree when the resource is created: each configuration would contain a list of gbeans to bind in the jndi tree when the configuration is loaded. Else, we will need some listener to listen to gbeans creation / destruction so that we can bind / unbind them from the global jndi context. Binding the resource during creation seems to be the simpler way. But what about the next time the server starts up. How is the context initialised? Do we populate during startup of each resource or application again or is persistence used in some way? In the case of listeners the above problem won't arise. A few questions: * I' m wondering how the global JNDI context will coexist with the existing ENC context, especially if the global jndi context is read-write ... Maybe there is no need for a local jndi context ... Yes that is a question i also have :-) . The local jndi context allows us to have app specific contexts and this has some advantages. A global jndi also has some advantages. Probably by default we can use the local context and if the user specifies a custom factory the global one or vice versa. * what is the purpose of the jndiname property ? If this is the key for a gbean in the jndi tree, I thought we could use the name attribute of the gbean: jdbc/TradeDataSource , jms/QueueConnectionFactory. These names can also be TradeDatasource so then we may need to add jdbc and if jdbc is there in the name as you mentioned do we need to add jdbc to the name or not. These are a few issues which made me propose the jndiName property . * what about conflicting names for JCA resources... currently there is nothing to prevent deploying JCA resource (or other resources that would be bound to jndi) with the same name I think deployment should fail with an resource already bound exception. Not sure if this or any other validation is implemented for the local context. Thanks Manu
[jira] Created: (GERONIMO-1929) Enable web apps exposed on separate ports
Enable web apps exposed on separate ports - Key: GERONIMO-1929 URL: http://issues.apache.org/jira/browse/GERONIMO-1929 Project: Geronimo Type: Bug Security: public (Regular issues) Components: Tomcat, web Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 We need to expose the ability tomcat and jetty have to expose separate web apps on separate ports. In tomcat native configuration you do this with multiple server elements in server.xml. We can do this with some very minor changes to the web builders. -- 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-1924) Need to register the tomcat jndi url handler somehow
[ http://issues.apache.org/jira/browse/GERONIMO-1924?page=all ]
David Jencks updated GERONIMO-1924:
---
Assign To: Jeff Genender
This appears to be at least minimally fixed in rev 397614. Jeff, could you
review this and see if it looks OK?
Need to register the tomcat jndi url handler somehow
Key: GERONIMO-1924
URL: http://issues.apache.org/jira/browse/GERONIMO-1924
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: Tomcat
Versions: 1.1
Reporter: David Jencks
Assignee: Jeff Genender
Priority: Blocker
Fix For: 1.1
Until recently we were using the Tomcat WebappLoader which has this code:
// Register a stream handler factory for the JNDI protocol
URLStreamHandlerFactory streamHandlerFactory =
new DirContextURLStreamHandlerFactory();
if (first) {
first = false;
try {
URL.setURLStreamHandlerFactory(streamHandlerFactory);
} catch (Exception e) {
// Log and continue anyway, this is not critical
log.error(Error registering jndi stream handler, e);
} catch (Throwable t) {
// This is likely a dual registration
log.info(Dual registration of jndi stream handler:
+ t.getMessage());
}
}
This is how tomcat finds anything in the web app when you call
servletContext.getResource(location_in_WEB_INF).
Since we recently stopped using the tomcat classloader, we need to do this
ourselves somewhere.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1900) Sample app links on welcome app are broken by default
[ http://issues.apache.org/jira/browse/GERONIMO-1900?page=all ] Prasad Kashyap reassigned GERONIMO-1900: Assign To: Prasad Kashyap Sample app links on welcome app are broken by default - Key: GERONIMO-1900 URL: http://issues.apache.org/jira/browse/GERONIMO-1900 Project: Geronimo Type: Bug Security: public(Regular issues) Components: usability, sample apps Versions: 1.1 Reporter: Aaron Mulder Assignee: Prasad Kashyap Priority: Blocker Fix For: 1.1 It would be nice to take users to a page that would prompt them to install the sample if they click a link to it and it's not present. However, automating this would require us to be able to construct a link into a portlet, which does not seem easy. For now, the welcome app can include pages at the locations where the sample apps will be bound, with text to the effect of: This sample has not yet been installed. To install it, visit the (URL)console(/URL) and select the Plugins page, click the Search for Plugins button, and select the (NAME HERE) sample to install. Then visit this same URL again to view the (NAME HERE) example. -- 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-1928) CLI doesn't allow --inPlace as an option
[ http://issues.apache.org/jira/browse/GERONIMO-1928?page=comments#action_12376789 ] Aaron Mulder commented on GERONIMO-1928: Are you sure it's not an option to the deploy or distribute command, as opposed to an option to the deploy tool as a whole? CLI doesn't allow --inPlace as an option Key: GERONIMO-1928 URL: http://issues.apache.org/jira/browse/GERONIMO-1928 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.1 The --inPlace argument is not accepted by the command line deployer. The following error is recieved: Error: No such command: '--inPlace' This option needs to be added to the syntax help as well. -- 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-1929) Enable web apps exposed on separate ports
[ http://issues.apache.org/jira/browse/GERONIMO-1929?page=comments#action_12376791 ] Aaron Mulder commented on GERONIMO-1929: Please keep me in the loop on this. Thanks. Enable web apps exposed on separate ports - Key: GERONIMO-1929 URL: http://issues.apache.org/jira/browse/GERONIMO-1929 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Tomcat, web Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 We need to expose the ability tomcat and jetty have to expose separate web apps on separate ports. In tomcat native configuration you do this with multiple server elements in server.xml. We can do this with some very minor changes to the web builders. -- 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-1384) Web app with no Geronimo plan makes all secure pages insecure
[ http://issues.apache.org/jira/browse/GERONIMO-1384?page=all ] Aaron Mulder updated GERONIMO-1384: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder Priority: Trivial (was: Blocker) Should try for the better fix for 1.1 if we're sitting around bored with nothing left to fix. Otherwise, should be a higher priority for 1.2. Web app with no Geronimo plan makes all secure pages insecure - Key: GERONIMO-1384 URL: http://issues.apache.org/jira/browse/GERONIMO-1384 Project: Geronimo Type: Bug Security: public(Regular issues) Components: security, web Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Trivial Fix For: 1.1 Attachments: security-reject.patch If you deploy a web application with certain pages/URLs protected by a login, but you don't include a Geronimo deployment plan, all those pages/URLs are unprotected. To replicate: Deploy this with no plan: http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war and then visit http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and click the links to secure and forbidden. Both links work, with no login prompt. Instead, you should get a login prompt and (since no realm was configured) all logins should fail. The web.xml in this case contains: security-constraint web-resource-collection web-resource-nameAdmin Role/web-resource-name url-pattern/protect/*/url-pattern /web-resource-collection auth-constraint role-namecontent-administrator/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameNo Access/web-resource-name url-pattern/forbidden/*/url-pattern /web-resource-collection auth-constraint/ /security-constraint login-config auth-methodFORM/auth-method realm-nameMYREALM/realm-name form-login-config form-login-page/auth/logon.html?param=test/form-login-page form-error-page/auth/logonError.html?param=test/form-error-page /form-login-config /login-config security-role role-namecontent-administrator/role-name /security-role -- 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-1367) Shutdown JAR should use deployer stored username/password
[ http://issues.apache.org/jira/browse/GERONIMO-1367?page=all ] Aaron Mulder updated GERONIMO-1367: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) Shutdown JAR should use deployer stored username/password - Key: GERONIMO-1367 URL: http://issues.apache.org/jira/browse/GERONIMO-1367 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: startup/shutdown, usability Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 It would be nice if the shutdown script used the username and password saved by the deployer so you didn't need to specify them or re-enter them. -- 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-1366) Maven deployment plugin should use deployer stored username/password
[ http://issues.apache.org/jira/browse/GERONIMO-1366?page=all ] Aaron Mulder updated GERONIMO-1366: --- Fix Version: 1.2 Maven deployment plugin should use deployer stored username/password Key: GERONIMO-1366 URL: http://issues.apache.org/jira/browse/GERONIMO-1366 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: Maven Plugins for G Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.2 It would be nice if the geronimo-deployment-plugin would pick up your saved username/password so you didn't need to code them into your maven file. That would introduce a dependency on the geronimo-util module. -- 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 ] Aaron Mulder updated GERONIMO-1360: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) Maybe the error message needs still more attention, and should present the option that the appropriate deployer is not active (or disabled if you're using the minimal tomcat install) 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 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
[jira] Updated: (GERONIMO-1174) Hot deployer should know when a file was last deployed
[ http://issues.apache.org/jira/browse/GERONIMO-1174?page=all ] Aaron Mulder updated GERONIMO-1174: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) Hot deployer should know when a file was last deployed -- Key: GERONIMO-1174 URL: http://issues.apache.org/jira/browse/GERONIMO-1174 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: Hot Deploy Dir Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 It would be nice if the hot deployer knew when a module was last deployed. That way, during startup, it could update deployments where the archive in the hot deployer directory had been updated while the server was down. This would go into HotDeployer.getDeploymentTime (which currently is essentially a noop). It seems like the most expedient way to implement this would be to add a method to the config store to get the deployment time (given a URI). David J suggests putting that method in a separate interface, something like TimedConfigStore or whatever. It's not clear that it should live forever in the config store, but that seems like the best short-term 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-1173) Make DatabaseInfo load from file; separate JDBC and XA portlets
[ http://issues.apache.org/jira/browse/GERONIMO-1173?page=all ] Aaron Mulder updated GERONIMO-1173: --- Fix Version: 1.1 (was: 1.x) Assign To: Aaron Mulder Priority: Critical (was: Major) Make DatabaseInfo load from file; separate JDBC and XA portlets --- Key: GERONIMO-1173 URL: http://issues.apache.org/jira/browse/GERONIMO-1173 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: databases, console Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 It would be nice if the database pool portlet loaded its information on known database drivers and URLs from a config file. That way we wouldn't need code changes to support new entries. (Note: this is different than the driver download feature, which does load parameters from a config file URL.) Once that is done, it would be nice to separate JDBC and XA drivers into separate portlets, reusing the same code but different config files to produce a separate list of supporting drivers/products. -- 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-1930) Make security real types into GBeans so they can be added in new/updated configurations
Make security real types into GBeans so they can be added in new/updated configurations --- Key: GERONIMO-1930 URL: http://issues.apache.org/jira/browse/GERONIMO-1930 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: security, console Versions: 1.1 Reporter: Aaron Mulder Assigned to: Aaron Mulder Fix For: 1.1 -- 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-1928) CLI doesn't allow --inPlace as an option
[ http://issues.apache.org/jira/browse/GERONIMO-1928?page=comments#action_12376794 ] Sachin Patel commented on GERONIMO-1928: Yes you're right. Verifed in place deployment worked. The help though for the individual command still did not list it as an option. I'll be glad to fix it. CLI doesn't allow --inPlace as an option Key: GERONIMO-1928 URL: http://issues.apache.org/jira/browse/GERONIMO-1928 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.1 The --inPlace argument is not accepted by the command line deployer. The following error is recieved: Error: No such command: '--inPlace' This option needs to be added to the syntax help as well. -- 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: (AMQ-688) Avoid blocking producers
[ https://issues.apache.org/activemq/browse/AMQ-688?page=comments#action_36103 ] Christopher A. Larrieu commented on AMQ-688: How can we collaborate on this work? The described functionality is crucial to ActiveMQ's success within our organization. Avoid blocking producers Key: AMQ-688 URL: https://issues.apache.org/activemq/browse/AMQ-688 Project: ActiveMQ Type: New Feature Components: Broker Versions: 4.0 RC 2 Reporter: Christopher A. Larrieu Assignee: Christopher A. Larrieu Fix For: incubation Original Estimate: 8 weeks Remaining: 8 weeks Our main goal is to avoid stalled producers by addressing the main culprit: too many undispatched messages in the broker's memory. Our motivation is to handle significant --though temporary-- imbalances between production and consumption rates. Reaching this goal entails specific broker modifications: 1. When memory gets tight, start dropping undispatched non-persistent messages. This is the first-cut attempt to maintain throughput of persistent messages. Unlike the approach documented at http://docs.codehaus.org/display/ACTIVEMQ/Slow+Consumer+Handling, the message dropping will only occur after the UsageManager reaches capacity. Non-persistent messages in dispatch lists will be dropped according to per-destination policy. Subscriptions can purge their own messages triggered via callback from the UsageManager. 2. Evict messages if memory remains tight, to be fetched from backing store prior to dispatch. ActiveMQ already supports this for persistent messages on Topics with durable subscriptions. If a consumer's prefetch buffer is full, the splash-over messages remain as IndirectMessageReference objects in the dispatch list, with the actual message body loaded from store on demand. I believe we can extend this approach for Queues as well. 3. Improve the efficiency with which evicted messages are loaded back into memory. Currently, they are loaded one at a time as needed. It would make sense to batch-load message sets periodically. This will require a significant shift in responsibilities between objects, since an IndirectMessageReference doesn't know about other instances that can be loaded in mass. The goal will be to keep each subscription dispatch list stocked with a decent number of messages in-memory to reasonably trade-off between it's consumer's performance and resource usage in the broker. As with everything else, we can implement this as a strategy class with the first cut implementing a simple resource allocation strategy: divvy up available memory amongst all subscriptions and keep that memory filled with messages for dispatch. I envision a worker task assuming responsibility for keeping these lists filled. 4. Even with the above modifications, we still can't entirely avoid blocked producers, so we'd like to add client-configurable time-outs to provide a bound for the time a producer can remain stalled. Maybe this should be a new attribute of ActiveMQConnection: maxProducerFlowControlWait. Calls to UsageManager.waitForSpace can take this quantity as an argument. Failure to reach sufficient space for the new message will throw an exception back up the stack and across the wire, letting the producer know that the message was not delivered. 5. Finally, we need to extend disk support for Topics that have only non-durable subscribers, otherwise their dispatch lists can fill up with persistent messages. In order to maintain compliance with JMS, it would be nice to provide some alternative to dropping persistent messages. One possible first cut is to layer this on top of a DurableTopicSubscription by creating an anonymous subscriber for every Topic that has only non-durable subscriptions. When all such subscriptions terminate, the broker can remove the anonymous subscriber. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1928) CLI doesn't allow --inPlace as an option
[ http://issues.apache.org/jira/browse/GERONIMO-1928?page=comments#action_12376795 ] Sachin Patel commented on GERONIMO-1928: Oh actually the distribute command does contains the help, the deploy command does not. CLI doesn't allow --inPlace as an option Key: GERONIMO-1928 URL: http://issues.apache.org/jira/browse/GERONIMO-1928 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.1 The --inPlace argument is not accepted by the command line deployer. The following error is recieved: Error: No such command: '--inPlace' This option needs to be added to the syntax help as well. -- 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-1135) Keystore password in System.properties
[ http://issues.apache.org/jira/browse/GERONIMO-1135?page=all ] Aaron Mulder updated GERONIMO-1135: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder I commented this out of the main configuration for 1.1, but forgot about the other ones. Should make sure it's commented out everywhere for 1.1 and then perhaps remove for 1.2 Keystore password in System.properties -- Key: GERONIMO-1135 URL: http://issues.apache.org/jira/browse/GERONIMO-1135 Project: Geronimo Type: Bug Security: public(Regular issues) Components: security Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 If you look at the System properties, the keystore and trust store passwords are in there. I'm not sure who puts them in there, but we need to find a way to stop that -- or else prevent applications from reading them? -- 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-1079) Better error for missing primkey-field
[ http://issues.apache.org/jira/browse/GERONIMO-1079?page=all ] Aaron Mulder updated GERONIMO-1079: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder (was: Gianny Damour) Priority: Critical (was: Major) Review for fixability in 1.1 Better error for missing primkey-field -- Key: GERONIMO-1079 URL: http://issues.apache.org/jira/browse/GERONIMO-1079 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, OpenEJB Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 I forgot the primkey-field for my CMP entity, and I got this: Error: Unable to distribute LoadMagus.ear: Could not deploy module caused by EJB [TestRunMachine] is misconfigured: could not find CMP fields for following pk fields: [TYPE] [MAX_VALUE] [MIN_VALUE] Now, I don't know where it got TYPE, MAX_VALUE, and MIN_VALUE from -- those are not fields on my EJB or the table or anything. I did have a prim-key-class set to java.lang.Integer, so perhaps it picked up the static fields on java.lang.Integer (if so why? I wouldn't have thought statics were relevant). It would be better if the error said missing primkey-field or prim-key-class does not have properties matching CMP field names or something like that. -- 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-1802) Console breakage in 1.1 branch
[ http://issues.apache.org/jira/browse/GERONIMO-1802?page=all ] Paul McMahan updated GERONIMO-1802: --- Attachment: removeDeprecations.patch This patch replaces calls to deprecated methods that are going to be removed from the kernel. It also replaces deprecated calls to DWR which changed after upgrading it to version 1.1. After applying this patch there is one remaining call to a deprecated kernel method in DerbyConnectionUtil.jva. I left that in place because it is already fixed in a separate patch that has not been applied yet (dbinfo.patch). Console breakage in 1.1 branch -- Key: GERONIMO-1802 URL: http://issues.apache.org/jira/browse/GERONIMO-1802 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: dbinfo.patch, dbpools.patch, jms.patch, jmsserver.patch, removeDeprecations.patch, webserver-listeners.patch, webserver.patch [This pass made on 4/24/2006] Welcome: OK Server/Information: OK Server/JVM: OK Server/Server Logs: OK Server/Shutdown: OK Server/Web Server: BROKEN - trying to stop a listener fails - unstable No stacktraces but frequently shows: [ConnectorPortlet] Incorrect connector reference Server/JMS Server: patch provided, also see GERONIMO-1906 Services/Common Libraries: OK Services/Database Pools: BROKEN Trying to deploy a db pool yields: java.lang.NoClassDefFoundError at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.class$(AbstractDeployCommand.java:44) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDeployerName(AbstractDeployCommand.java:64) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.init(AbstractDeployCommand.java:60) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.init(DistributeCommand.java:35) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createDistributeCommand(JMXDeploymentManager.java:299) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.distribute(JMXDeploymentManager.java:173) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:970) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:333) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) Services/JMS Resources: BROKEN Trying to deploy a JMS resource yields: java.lang.NoClassDefFoundError at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.class$(AbstractDeployCommand.java:44) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDeployerName(AbstractDeployCommand.java:64) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.init(AbstractDeployCommand.java:60) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.init(DistributeCommand.java:35) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createDistributeCommand(JMXDeploymentManager.java:299) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.distribute(JMXDeploymentManager.java:173) at org.apache.geronimo.console.jmsmanager.wizard.AbstractHandler.save(AbstractHandler.java:633) at org.apache.geronimo.console.jmsmanager.wizard.DeployHandler.actionBeforeView(DeployHandler.java:40) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) Applications/Deploy New: OK Applications/Application EARs: OK Applications/Web Apps: OK Applications/EJB JARS: looks OK but not thoroughly tested yet Applications/J2EE Connectors: OK Applications/App Clients: looks OK but not thoroughly tested yet Applications/System Modules: OK Applications/Plugins: OK Security/Console Realm: OK Security/Security Realm: BROKEN Fails when saving plan with exception: java.lang.NoClassDefFoundError at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.class$(AbstractDeployCommand.java:44) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDeployerName(AbstractDeployCommand.java:64) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.init(AbstractDeployCommand.java:60) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.init(DistributeCommand.java:35) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createDistributeCommand(JMXDeploymentManager.java:299) at
[jira] Updated: (GERONIMO-1056) Redeploy database pool, app blows up (in CMP finder/prefetch code)
[ http://issues.apache.org/jira/browse/GERONIMO-1056?page=all ] Aaron Mulder updated GERONIMO-1056: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder Priority: Critical (was: Major) Sounds like it should be fixed already (by automatically restarting the application)? Need to confirm behavior in 1.1. Redeploy database pool, app blows up (in CMP finder/prefetch code) -- Key: GERONIMO-1056 URL: http://issues.apache.org/jira/browse/GERONIMO-1056 Project: Geronimo Type: Bug Security: public(Regular issues) Components: connector, naming, OpenEJB Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Using Head (10/10). I redeployed a database pool, and the app that uses in then blew up with this: Caused by: java.lang.NullPointerException at org.tranql.sql.DataSourceDelegate.getConnection(DataSourceDelegate.java:36) at org.tranql.sql.jdbc.JDBCQueryCommand.execute(JDBCQueryCommand.java:61) at org.tranql.sql.prefetch.PrefetchGroupHandler.execute(PrefetchGroupHandler.java:160) at org.openejb.entity.cmp.CMPFinder.execute(CMPFinder.java:95) at org.openejb.entity.cmp.CollectionValuedFinder.execute(CollectionValuedFinder.java:81) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) at org.openejb.security.EJBSecurityInterceptor.invoke(EJBSecurityInterceptor.java:104) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) at org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136) at org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:90) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119) ... 55 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1023) Web DD option to disable directory listings
[ http://issues.apache.org/jira/browse/GERONIMO-1023?page=all ] Aaron Mulder updated GERONIMO-1023: --- Fix Version: 1.1 (was: 1.2) Assign To: Aaron Mulder Will look at for 1.1 if other people can provide the appropriate Tomcat/Jetty configuration options (default servlets or whatnot). Web DD option to disable directory listings --- Key: GERONIMO-1023 URL: http://issues.apache.org/jira/browse/GERONIMO-1023 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: web Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Minor Fix For: 1.1 It would be nice if there was a simple web deployment plan option that would disable directory listings. For now, you can just use a welcome file list, but still, that means you need a welcome file (for example) in your images directory, in your CSS directory, in your JS directory, etc. -- 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-944) Bundle a JavaMail implementation SMTP provider
[ http://issues.apache.org/jira/browse/GERONIMO-944?page=all ] Aaron Mulder updated GERONIMO-944: -- Fix Version: 1.1 (was: 1.x) Assign To: Aaron Mulder Priority: Critical (was: Major) I believe this is fixed. Try activating JavaMail and using a mail resource reference in 1.1. Bundle a JavaMail implementation SMTP provider Key: GERONIMO-944 URL: http://issues.apache.org/jira/browse/GERONIMO-944 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: mail Versions: 1.0-M4 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 I'm not sure what the state is of our JavaMail implementation. I know we have our own spec JAR and I think I've heard that we have our own SMTP provider, but that it's not part of the Geronimo distribution and as a result the Sun JavaMail provider is recommended. I'd like to straighten this out for M5 so we can provide basic JavaMail resource mapping (at least for outgoing mail via SMTP) as part of the standard package. If this is not possible for some reason, please retarget this issue to 1.0 and suggest a path forward. Thanks. -- 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-897) Finish implementing JMS Broker portlet
[ http://issues.apache.org/jira/browse/GERONIMO-897?page=all ] Aaron Mulder updated GERONIMO-897: -- Fix Version: 1.1 (was: 1.x) Assign To: Aaron Mulder Priority: Critical (was: Major) I believe this JMS broker portlet was replaced with one that doesn't let you do much WRT the broker. Should confirm for 1.1 and if true, add a separate issue to add more functionality to the new portlet. Finish implementing JMS Broker portlet -- Key: GERONIMO-897 URL: http://issues.apache.org/jira/browse/GERONIMO-897 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0-M5 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 The JMS broker portlet applications/console-standard/src/java/org/apache/geronimo/console/jmsmanager/server/JMSBrokerPortlet.java has a few missing features -- adding and removing a broker, and editing a broker if there's anything to edit. Also, when you stop and start a broker, it doesn't actually start again -- it gets hung up in the starting state. -- 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 ] Aaron Mulder updated GERONIMO-847: -- Fix Version: 1.1 (was: 1.x) Assign To: Aaron Mulder Priority: Critical (was: Major) Check what happens in 1.1. 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 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] Updated: (GERONIMO-734) Adding CORBA settings to local-only EJB appears to give NPE
[ http://issues.apache.org/jira/browse/GERONIMO-734?page=all ] Aaron Mulder updated GERONIMO-734: -- Fix Version: 1.1 (was: 1.x) Assign To: Aaron Mulder Priority: Critical (was: Major) Should produce a better message than an NPE Adding CORBA settings to local-only EJB appears to give NPE --- Key: GERONIMO-734 URL: http://issues.apache.org/jira/browse/GERONIMO-734 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 I added a tss-link to an EJB with only local and local-home interfaces. I suspect the problem is the lack of remote interfaces, in which case this should result in a deployment error. What actually happened was: org.openejb.corba.CORBAException: java.lang.NullPointerException at org.openejb.corba.Adapter.init(Adapter.java:127) at org.openejb.corba.AdapterEntity.init(AdapterEntity.java:85) at org.openejb.corba.AdapterWrapper.start(AdapterWrapper.java:87) at org.openejb.corba.TSSBean.registerContainer(TSSBean.java:207) at org.openejb.corba.TSSBean$$FastClassByCGLIB$$57d49a76.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:719) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:94) at org.openejb.corba.TSSBean$$EnhancerByCGLIB$$7369adf9.registerContainer(generated) at org.openejb.GenericEJBContainer.doStart(GenericEJBContainer.java:396) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:850) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:328) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:111) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:133) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:141) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) at org.apache.geronimo.kernel.KernelGBean.startRecursiveGBean(KernelGBean.java:72) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:754) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:177) at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117) at mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219) at sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSubjectInvoker.java:31) at mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjectInvoker.java:90) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:500) at mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:163) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(RMIConnectionSubjectInvoker.java:86) at
[jira] Updated: (GERONIMO-454) Support Group Name = Role Name Role Mapping
[ http://issues.apache.org/jira/browse/GERONIMO-454?page=all ] Aaron Mulder updated GERONIMO-454: -- Fix Version: 1.1 (was: 1.x) Assign To: Aaron Mulder (was: Alan Cabrera) Priority: Minor (was: Major) Review for 1.1. Would it be simple to have a flag saying map all principals of type o.a.g.security.realm.provider.GeronimoGroupPrinicipal to a J2EE role of the same name, if one exists? Support Group Name = Role Name Role Mapping --- Key: GERONIMO-454 URL: http://issues.apache.org/jira/browse/GERONIMO-454 Project: Geronimo Type: Improvement Components: deployment, security Versions: 1.0-M2 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Minor Fix For: 1.1 Currently, you must manually map principals to roles in the security component of a deployment descriptor. In the common case where group names match role names, this seems like unnecessary overhead. Alan and I talked and our plan is to make the role-mapping parts of the security elements look something like this: security ... automatic-role-mapping? principal-classfoo.GroupPrincipal/principal-class* /automatic-role-mapping role-mapping? ... /role-mapping /security The automatic-role-mapping is the new bit. If you specify that element empty, it would map every principal type the security realm considers to be a group to roles. For example, if you configure the seucrity realm to consider the principal class foo.GroupPrincipal as a role, and use an empty automatic-role-mapping element, that's what you'd get. You can also manually specify one or more principal classes that should be automatically mapped to roles. In any of these cases, the automatic mapping is done based on the role name and group name matching. If you specify automatic mapping *and* individual role mapping, then the user just needs to qualify for the role based on either one or the other (not both). So you could use a manual role mapping to add eligible users on top of the automatic role mapping, but not to subtract users from the automatic role mapping. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-438) Deployer.deploy arguments inconsistent
[ http://issues.apache.org/jira/browse/GERONIMO-438?page=all ] Aaron Mulder reassigned GERONIMO-438: - Assign To: Dain Sundstrom Yeah, it's been around for a while :) Deployer.deploy arguments inconsistent -- Key: GERONIMO-438 URL: http://issues.apache.org/jira/browse/GERONIMO-438 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M2 Reporter: Aaron Mulder Assignee: Dain Sundstrom Fix For: Wish List One deploy method starts with the arguments: File module, File plan Another overloaded deploy method starts with the arguments: File plan, File module These should not be reversed, but we need to carefully hunt down usages since the types alone won't cause the usages to be flagged if one is switched. -- 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-1802) Console breakage in 1.1 branch
[ http://issues.apache.org/jira/browse/GERONIMO-1802?page=comments#action_12376817 ] Paul McMahan commented on GERONIMO-1802: As of 4/27 the following patches have been applied: dbpools.patch jms.patch jmsserver.patch The remaining patches should be applied in the following order: webserver-listeners.patch dbinfo.patch removeDeprecations.patch webserver.patch is no longer needed since GERONIMO-1877 has been fixed: After these patches are applied the console portlet code should be basically back in working order and we could consider closing this JIRA, allowing any remaining console items that are found to be handled in new JIRAs. Console breakage in 1.1 branch -- Key: GERONIMO-1802 URL: http://issues.apache.org/jira/browse/GERONIMO-1802 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: dbinfo.patch, dbpools.patch, jms.patch, jmsserver.patch, removeDeprecations.patch, webserver-listeners.patch, webserver.patch [This pass made on 4/24/2006] Welcome: OK Server/Information: OK Server/JVM: OK Server/Server Logs: OK Server/Shutdown: OK Server/Web Server: BROKEN - trying to stop a listener fails - unstable No stacktraces but frequently shows: [ConnectorPortlet] Incorrect connector reference Server/JMS Server: patch provided, also see GERONIMO-1906 Services/Common Libraries: OK Services/Database Pools: BROKEN Trying to deploy a db pool yields: java.lang.NoClassDefFoundError at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.class$(AbstractDeployCommand.java:44) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDeployerName(AbstractDeployCommand.java:64) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.init(AbstractDeployCommand.java:60) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.init(DistributeCommand.java:35) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createDistributeCommand(JMXDeploymentManager.java:299) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.distribute(JMXDeploymentManager.java:173) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:970) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:333) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163) Services/JMS Resources: BROKEN Trying to deploy a JMS resource yields: java.lang.NoClassDefFoundError at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.class$(AbstractDeployCommand.java:44) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDeployerName(AbstractDeployCommand.java:64) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.init(AbstractDeployCommand.java:60) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.init(DistributeCommand.java:35) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createDistributeCommand(JMXDeploymentManager.java:299) at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.distribute(JMXDeploymentManager.java:173) at org.apache.geronimo.console.jmsmanager.wizard.AbstractHandler.save(AbstractHandler.java:633) at org.apache.geronimo.console.jmsmanager.wizard.DeployHandler.actionBeforeView(DeployHandler.java:40) at org.apache.geronimo.console.MultiPagePortlet.processAction(MultiPagePortlet.java:114) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) Applications/Deploy New: OK Applications/Application EARs: OK Applications/Web Apps: OK Applications/EJB JARS: looks OK but not thoroughly tested yet Applications/J2EE Connectors: OK Applications/App Clients: looks OK but not thoroughly tested yet Applications/System Modules: OK Applications/Plugins: OK Security/Console Realm: OK Security/Security Realm: BROKEN Fails when saving plan with exception: java.lang.NoClassDefFoundError at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.class$(AbstractDeployCommand.java:44) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.getDeployerName(AbstractDeployCommand.java:64) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.init(AbstractDeployCommand.java:60) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.init(DistributeCommand.java:35) at
[jira] Updated: (GERONIMO-436) JSR-88: Targets Ignored
[ http://issues.apache.org/jira/browse/GERONIMO-436?page=all ] Aaron Mulder updated GERONIMO-436: -- Fix Version: 1.1 (was: 1.x) Assign To: Aaron Mulder Priority: Critical (was: Major) Believe this has some more visibility now (e.g. a static config store and a separate config store for runtime changes; a separate config store for eclipse, etc.) JSR-88: Targets Ignored --- Key: GERONIMO-436 URL: http://issues.apache.org/jira/browse/GERONIMO-436 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M2 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 The current JSR-88 deployer (JMXDeploymentManager) may potentially provide a list of targets for getTargets() -- one per config store. However, all the methods that take an array of Target or TargetModuleID objects ignore the specified Targets. -- 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-411) Add Hash Password Rewrite to File Realm
[ http://issues.apache.org/jira/browse/GERONIMO-411?page=all ]
Aaron Mulder updated GERONIMO-411:
--
Fix Version: 1.1
(was: 1.2)
Assign To: Aaron Mulder
Someone on the user list said PW hashing was an absolute requirement for their
project. Review for 1.1 if time permits.
Add Hash Password Rewrite to File Realm
---
Key: GERONIMO-411
URL: http://issues.apache.org/jira/browse/GERONIMO-411
Project: Geronimo
Type: Improvement
Components: security
Versions: 1.0-M2
Reporter: Aaron Mulder
Assignee: Aaron Mulder
Priority: Minor
Fix For: 1.1
It would be nice if the properties file realm could rewrite your properties
file with hashed passwords when it reads it. We would need to be able to
recognize hashed vs. unhashed entries and perhaps even different algorithms.
Perhaps it could go like this:
user1=plaintext
user2=MD5{...}
user3=SHA1{...}
Anyway, the idea is that this could be a reasonably secure alternative, but
you still wouldn't need to manually hash things to add or update entries --
just put a plain text entry in and the next time the server reads the file it
would hash it for you.
I guess we'd need to synchronize on the hash operation to avoid threading
problems if multiple apps or whatever use the same properties file, but it
shouldn't be bad if we only rewrite the file if we find any plain text
entries.
--
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-1421) DB portlet failure in Tomcat only
[ http://issues.apache.org/jira/browse/GERONIMO-1421?page=comments#action_12376823 ] Paul McMahan commented on GERONIMO-1421: This works ok now. i.e. in the tomcat version you can add ;create=true for the generated URL without getting punted out of the wizard, the test connection succeeds, and the new db shows up in the db manager. DB portlet failure in Tomcat only - Key: GERONIMO-1421 URL: http://issues.apache.org/jira/browse/GERONIMO-1421 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console, Tomcat Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 - create a new database pool using the DB portlet - select the Derby Embedded type - pick the derby or derby-client JAR - give it a new or existing database name - add ;create=true to the end of the generated URL - click test This procedure works in the Jetty build but does not work in the Tomcat build. In Tomcat, it just redirects to the main screen for that portlet without any error message. The database is actually created (visible in the DB Manager portlet). This does not happen if you remove ;create=true from the URL and use an existing database. -- 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-1927) Need way to disable or make invisible security when using deployer.jar
[ http://issues.apache.org/jira/browse/GERONIMO-1927?page=all ] Aaron Mulder resolved GERONIMO-1927: Resolution: Fixed Need way to disable or make invisible security when using deployer.jar -- Key: GERONIMO-1927 URL: http://issues.apache.org/jira/browse/GERONIMO-1927 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 We need a way to make the deployer security invisible to users. Proposal is to let them put .geronimo-deployer into their copy of deployer.jar, and have the code that looks for this file first search the classpath, then the users home directory. This will also let you have different logins for different servers. -- 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
