[jira] Created: (AMQ-1007) XMPP support (Jabber support) so existing Jabber clients can be used to interact with and monitor ActiveMQ messages
XMPP support (Jabber support) so existing Jabber clients can be used to interact with and monitor ActiveMQ messages --- Key: AMQ-1007 URL: https://issues.apache.org/activemq/browse/AMQ-1007 Project: ActiveMQ Issue Type: New Feature Components: Transport Reporter: james strachan Assigned To: james strachan Fix For: 4.1 This is particularly useful for demos or testing things out in development. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1007) XMPP support (Jabber support) so existing Jabber clients can be used to interact with and monitor ActiveMQ messages
[ https://issues.apache.org/activemq/browse/AMQ-1007?page=all ] james strachan resolved AMQ-1007. - Resolution: Fixed The activemq-xmpp module provides the functionality, for documentation see http://activemq.org/site/xmpp.html XMPP support (Jabber support) so existing Jabber clients can be used to interact with and monitor ActiveMQ messages --- Key: AMQ-1007 URL: https://issues.apache.org/activemq/browse/AMQ-1007 Project: ActiveMQ Issue Type: New Feature Components: Transport Reporter: james strachan Assigned To: james strachan Fix For: 4.1 This is particularly useful for demos or testing things out in development. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-506) Jabber transport missing
[ https://issues.apache.org/activemq/browse/AMQ-506?page=all ] james strachan resolved AMQ-506. Fix Version/s: 4.1 (was: 4.2) Resolution: Fixed Now back as activemq-xmpp Jabber transport missing Key: AMQ-506 URL: https://issues.apache.org/activemq/browse/AMQ-506 Project: ActiveMQ Issue Type: Improvement Components: Transport Affects Versions: 4.0 M4 Reporter: Guillaume Nodet Fix For: 4.1 -- 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-40) jabber support as client server
[ https://issues.apache.org/activemq/browse/AMQ-40?page=comments#action_37289 ] james strachan commented on AMQ-40: --- FWIW in 4.1 its now via xmpp://host:port For more details see http://activemq.org/site/xmpp.html jabber support as client server - Key: AMQ-40 URL: https://issues.apache.org/activemq/browse/AMQ-40 Project: ActiveMQ Issue Type: New Feature Reporter: james strachan Priority: Minor Fix For: 3.1 we now support a new transport jabber://localhost:61606 which allows a Jabber client to connect to ActiveMQ and talk Jabber (XMPP) to the ActiveMQ broker. This allows any Jabber client in any language to talk natively to ActiveMQ. -- 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-734) Network connections do not reconnect when using static: with failover=true
[
https://issues.apache.org/activemq/browse/AMQ-734?page=comments#action_37294 ]
Eric Wood commented on AMQ-734:
---
We can reproduce this issue using the current build of 4.0.2. We are running a
distributed queue between two embedded brokers over an unreliable network
(wireless). We had been using 4.0.1, but the brokers did not reestablish the
bridge when it was stopped due to inactivity timeout. We tried 4.0.2 and it
worked great for a while, but eventually one of the reconnect attempts failed.
On the receiver side broker (called CTSServer) we see in the logs wire format
negotiation taking place, but on the send side broker (called CTSClient) we get
the following in the log:
[java] 12:42:12,236 DEBUG DurableConduitBridge:69 - Forwarding messages
for durable destination: queue://TEST.FOO
[java] 12:42:12,237 DEBUG DemandForwardingBridge:289 - stopping CTSClient
bridge to CTSServer is disposed already ? false
[java] 12:42:12,240 DEBUG DemandForwardingBridge:308 - CTSClient bridge to
CTSServer stopped
[java] 12:42:12,241 DEBUG DemandForwardingBridge:289 - stopping CTSClient
bridge to CTSServer is disposed already ? true
[java] 12:42:12,242 DEBUG DemandForwardingBridge:308 - CTSClient bridge to
CTSServer stopped
[java] 12:42:12,244 INFO NetworkConnector:96 - Establishing network
connection between from vm://CTSClient?network=true to tcp://10.134.0.1:61616
[java] 12:42:15,986 DEBUG WireFormatNegotiator:65 - Sending:
WireFormatInfo { version=1, properties={TightEncodingEnabled=true,
TcpNoDelayEnabled=true, SizePrefixDisabled=false, StackTraceEnabled=true,
MaxInactivityDuration=3, CacheEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
[java] 12:42:15,987 DEBUG TcpTransport:133 - TCP consumer thread starting
[java] 12:42:18,957 DEBUG WireFormatNegotiator:95 - Received WireFormat:
WireFormatInfo { version=1, properties={StackTraceEnabled=true,
TightEncodingEnabled=true, TcpNoDelayEnabled=true, SizePrefixDisabled=false,
MaxInactivityDuration=3, CacheEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
[java] 12:42:18,957 DEBUG WireFormatNegotiator:102 -
tcp:///10.134.0.1:61616 before negotiation: OpenWireFormat{version=1,
cacheEnabled=false, stackTraceEnabled=false, tightEncodingEnabled=false,
sizePrefixDisabled=false}
[java] 12:42:18,958 DEBUG WireFormatNegotiator:113 -
tcp:///10.134.0.1:61616 after negotiation: OpenWireFormat{version=1,
cacheEnabled=true, stackTraceEnabled=true, tightEncodingEnabled=true,
sizePrefixDisabled=false}
[java] 12:42:21,838 DEBUG Service:221 - Async error occurred:
javax.jms.InvalidClientIDException: Broker: CTSClient - Client:
NC_CTSServer_inboundCTSClient already connected
[java] javax.jms.InvalidClientIDException: Broker: CTSClient - Client:
NC_CTSServer_inboundCTSClient already connected
[java] at
org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:180)
[java] at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:70)
[java] at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:70)
[java] at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:70)
[java] at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:83)
[java] at
org.apache.activemq.broker.AbstractConnection.processAddConnection(AbstractConnection.java:633)
[java] at
org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:120)
[java] at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:237)
[java] at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:61)
[java] at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92)
[java] at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67)
[java] at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:77)
[java] at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:45)
[java] at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:59)
[java] at
org.apache.activemq.network.DemandForwardingBridgeSupport.startLocalBridge(DemandForwardingBridgeSupport.java:225)
[java] at
org.apache.activemq.network.DemandForwardingBridgeSupport$3.run(DemandForwardingBridgeSupport.java:191)
[java] 12:42:21,840 INFO DemandForwardingBridge:230 - Network connection
between vm://CTSClient#728 and tcp:///10.134.0.1:61616(CTSServer) has been
established.
[java] 12:42:21,851 INFO DemandForwardingBridge:432 - Network connection
between vm://CTSClient#728 and tcp:///10.134.0.1:61616 shutdown due to a local
error: javax.jms.InvalidClientIDException: Broker: CTSClient - Client:
Running ActiveMQ under Harmony!
Hey, Just wanted to let you guys know that I tried running ActiveMQ using the Harmony JVM and here are the results: Harmon: latest from tonight Platform: Linux SUSE 10 ActiveMQ: 4.0.2 RC6 Using default config it bombed with: [EMAIL PROTECTED]:~/Desktop/incubator-activemq-4.0.2/bin ./activemq ACTIVEMQ_HOME: /home/chirino/Desktop/incubator-activemq-4.0.2 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: UID[-6822e1e4:10e87cde34a:-8000]:dualcoreamd:1 INFO BrokerService - ActiveMQ 4.0.2 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ WARN ManagementContext - Failed to start jmx connector: javax.naming.NoInitialContextException: Failed to create InitialContext using factory specified in hashtable [EMAIL PROTECTED] [Root exception is java.lang.ClassNotFoundException: class null not found] INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] java: /home/chirino/sandbox/harmony/enhanced/drlvm/trunk/vm/vmcore/src/object/object_handles.cpp:100: void GcFrame::add_object(ManagedObject**): Assertion `__null == *p || (*p = vm_heap_base_address() *p vm_heap_ceiling_address())' failed. SIGABRT in VM code. Stack trace: addr2line: '[vdso]': No such file [EMAIL PROTECTED]:~/Desktop/incubator-activemq-4.0.2/bin But if you disable persistence in ActiveMQ, it runs great! See: [EMAIL PROTECTED]:~/Desktop/incubator-activemq-4.0.2/bin ./activemq ACTIVEMQ_HOME: /home/chirino/Desktop/incubator-activemq-4.0.2 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: UID[-68563ba8:10e87cea873:-8000]:dualcoreamd:1 INFO BrokerService - ActiveMQ 4.0.2 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ WARN ManagementContext - Failed to start jmx connector: javax.naming.NoInitialContextException: Failed to create InitialContext using factory specified in hashtable [EMAIL PROTECTED] [Root exception is java.lang.ClassNotFoundException: class null not found] INFO TransportServerThreadSupport - Listening for connections at: tcp://dualcoreamd:61616 WARN MulticastDiscoveryAgent- brokerName not set INFO TransportConnector - Connector default Started INFO TransportServerThreadSupport - Listening for connections at: stomp://dualcoreamd:61613 INFO TransportConnector - Connector stomp Started INFO NetworkConnector - Network Connector default Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:dualcoreamd-27697-1161919638290-0:0) started Kudos to the Harmony team! Great work! -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Commented: (SM-722) ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when a SOAP invocation contains whitespace nodes
[
https://issues.apache.org/activemq/browse/SM-722?page=comments#action_37290 ]
Guillaume Nodet commented on SM-722:
I don't think the problem comes from here.
I would rather take a look at the
SourceTransformer#createDocumentBuilderFactory method
which has the following code:
{code:lang=java,title=org.apache.servicemix.jbi.jaxp.SourceTransformer}
public DocumentBuilderFactory createDocumentBuilderFactory() {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
factory.setIgnoringElementContentWhitespace(true);
factory.setIgnoringComments(true);
return factory;
}
{code}
ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when
a SOAP invocation contains whitespace nodes
-
Key: SM-722
URL: https://issues.apache.org/activemq/browse/SM-722
Project: ServiceMix
Issue Type: Bug
Components: servicemix-core
Affects Versions: 3.0
Reporter: Renaud Bruyeron
Fix For: 3.0.1
The problem is in the code below in ExtendedXMLStreamReader, which is used by
SoapMarshaler to extract the SOAP message from a http invocation, and put it
in a NormalizedMessage.
I have a SOAP message that has things like this: text /text. The
whitespace is significant, and should not be trimmed, yet the message comes
out as text/.
Is there a reason for explicitely doing this?
public int nextTag() throws XMLStreamException {
int eventType = next();
while((eventType == XMLStreamConstants.CHARACTERS isWhiteSpace())
// skip whitespace
|| (eventType == XMLStreamConstants.CDATA isWhiteSpace())
// skip whitespace
|| eventType == XMLStreamConstants.SPACE
|| eventType == XMLStreamConstants.PROCESSING_INSTRUCTION
|| eventType == XMLStreamConstants.COMMENT
) {
eventType = next();
}
if (eventType != XMLStreamConstants.START_ELEMENT eventType !=
XMLStreamConstants.END_ELEMENT) {
throw new XMLStreamException(expected start or end tag,
getLocation());
}
return eventType;
}
--
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-722) ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when a SOAP invocation contains whitespace nodes
[
https://issues.apache.org/activemq/browse/SM-722?page=comments#action_37291 ]
Guillaume Nodet commented on SM-722:
I don't think the problem comes from here.
I would rather take a look at the
SourceTransformer#createDocumentBuilderFactory method
which has the following code:
{code:lang=java|title=org.apache.servicemix.jbi.jaxp.SourceTransformer}
public DocumentBuilderFactory createDocumentBuilderFactory() {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
factory.setIgnoringElementContentWhitespace(true);
factory.setIgnoringComments(true);
return factory;
}
{code}
Could you try removing the setIgnoringXxx calls and see if it changes ?
ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when
a SOAP invocation contains whitespace nodes
-
Key: SM-722
URL: https://issues.apache.org/activemq/browse/SM-722
Project: ServiceMix
Issue Type: Bug
Components: servicemix-core
Affects Versions: 3.0
Reporter: Renaud Bruyeron
Fix For: 3.0.1
The problem is in the code below in ExtendedXMLStreamReader, which is used by
SoapMarshaler to extract the SOAP message from a http invocation, and put it
in a NormalizedMessage.
I have a SOAP message that has things like this: text /text. The
whitespace is significant, and should not be trimmed, yet the message comes
out as text/.
Is there a reason for explicitely doing this?
public int nextTag() throws XMLStreamException {
int eventType = next();
while((eventType == XMLStreamConstants.CHARACTERS isWhiteSpace())
// skip whitespace
|| (eventType == XMLStreamConstants.CDATA isWhiteSpace())
// skip whitespace
|| eventType == XMLStreamConstants.SPACE
|| eventType == XMLStreamConstants.PROCESSING_INSTRUCTION
|| eventType == XMLStreamConstants.COMMENT
) {
eventType = next();
}
if (eventType != XMLStreamConstants.START_ELEMENT eventType !=
XMLStreamConstants.END_ELEMENT) {
throw new XMLStreamException(expected start or end tag,
getLocation());
}
return eventType;
}
--
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-722) ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when a SOAP invocation contains whitespace nodes
[
https://issues.apache.org/activemq/browse/SM-722?page=comments#action_37293 ]
Renaud Bruyeron commented on SM-722:
mmhh, I am not sure the ConsumerProcessor is using a sourceTransformer to parse
the incoming SOAP message:
{code:java|title=org.apache.servicemix.http.processors.ConsumerProcessor}
SoapMessage message =
soapHelper.getSoapMarshaler().createReader().read(
request.getInputStream(),
request.getHeader(Constants.HEADER_CONTENT_TYPE));
{code}
In my case, the SoapReader uses the readSoapUsingStax(...) method. The relevant
code is:
{code:title=org.apache.servicemix.soap.marshalers.SoapReader line 187}
private SoapMessage readSoapUsingStax(InputStream is) throws Exception {
SoapMessage message = new SoapMessage();
XMLStreamReader reader =
marshaler.getInputFactory().createXMLStreamReader(is);
reader = new ExtendedXMLStreamReader(reader);
// skipping...
// Create Source for content
if (reader.nextTag() != XMLStreamConstants.END_ELEMENT) {
QName childName = reader.getName();
message.setBodyName(childName);
// Check for fault
if (childName.equals(new QName(soapUri, SoapMarshaler.FAULT))) {
message.setFault(readFaultUsingStax(reader));
} else {
message.setSource(new StaxSource(new
FragmentStreamReader(reader)));
}
}
{code}
As you can see, it is using the ExtendedXMLStreamReader to wrap the reader,
therefore whitespace-only nodes get trimmed.
By the way in DOM mode, the SoapReader uses the DocumentBuilderFactory directly:
{code:title=org.apache.servicemix.soap.marshalers.SoapReader line 91}
private SoapMessage readSoapUsingDom(InputStream is) throws Exception {
SoapMessage message = new SoapMessage();
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(true);
Document doc = factory.newDocumentBuilder().parse(is);
{code}
ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when
a SOAP invocation contains whitespace nodes
-
Key: SM-722
URL: https://issues.apache.org/activemq/browse/SM-722
Project: ServiceMix
Issue Type: Bug
Components: servicemix-core
Affects Versions: 3.0
Reporter: Renaud Bruyeron
Fix For: 3.0.1
The problem is in the code below in ExtendedXMLStreamReader, which is used by
SoapMarshaler to extract the SOAP message from a http invocation, and put it
in a NormalizedMessage.
I have a SOAP message that has things like this: text /text. The
whitespace is significant, and should not be trimmed, yet the message comes
out as text/.
Is there a reason for explicitely doing this?
public int nextTag() throws XMLStreamException {
int eventType = next();
while((eventType == XMLStreamConstants.CHARACTERS isWhiteSpace())
// skip whitespace
|| (eventType == XMLStreamConstants.CDATA isWhiteSpace())
// skip whitespace
|| eventType == XMLStreamConstants.SPACE
|| eventType == XMLStreamConstants.PROCESSING_INSTRUCTION
|| eventType == XMLStreamConstants.COMMENT
) {
eventType = next();
}
if (eventType != XMLStreamConstants.START_ELEMENT eventType !=
XMLStreamConstants.END_ELEMENT) {
throw new XMLStreamException(expected start or end tag,
getLocation());
}
return eventType;
}
--
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
Heads up: new ServiceMix console
I've hacked up a simple web app which connect to a running servicemix instance using jmx. See http://servicemix.goopen.org/site/console.html There are still a lot of stuff to do, so feel free to take a look at it, criticize, and submit patches :) -- Cheers, Guillaume Nodet
Re: Old activemq and activecluster
This is for OpenEJB2, its got a few classes that use WADI 2.0m1 bits
which in turn use old/m1 active{io|mq|cluster} deps. I upgraded the
active{io|mq|cluster} deps and fixed a few imports to use
org.apache.*, but I seem problems building as no org.activecluster
classes are on the CP (they are org.apache.activecluster).
I checked if WADI's trunk was using these but its using the new deps,
so I went to upgrade the WADI deps in OpenEJB2 and then ran into a
ton of compile errors... so I gave up :-(
I could certainly exclude the old active{io|mq|cluster} in G... which
may or may not work, but I would rather have all of the deps in
sync... otherwise I imagine some very strange errors may pop up.
With OpenEJB2 using latest active{io|mq|cluster} and wadi snaps the
openejb-core module pukes out:
snip
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBContainerMonitor.java:
[23,35] package org.codehaus.wadi.gridstate does not exist
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBContainerMonitor.java:
[32,18] cannot resolve symbol
symbol : class Dispatcher
location: class
org.apache.openejb.cluster.server.DefaultEJBContainerMonitor
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBContainerMonitor.java:
[34,38] cannot resolve symbol
symbol : class Dispatcher
location: class
org.apache.openejb.cluster.server.DefaultEJBContainerMonitor
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java:
[29,35] package org.codehaus.wadi.gridstate does not exist
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java:
[30,49] package org.codehaus.wadi.gridstate.activecluster does not exist
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java:
[31,40] package org.codehaus.wadi.gridstate.impl does not exist
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java:
[35,30] cannot resolve symbol
symbol : class DistributableAttributesFactory
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java:
[36,30] cannot resolve symbol
symbol : class DistributableSessionFactory
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java:
[37,30] cannot resolve symbol
symbol : class DistributableValueFactory
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java:
[39,30] cannot resolve symbol
symbol : class DummyRouter
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java:
[42,30] cannot resolve symbol
symbol : class SessionToContextPoolAdapter
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java:
[47,30] cannot resolve symbol
symbol : class StandardSessionWrapperFactory
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java:
[69,18] cannot resolve symbol
symbol : class Dispatcher
location: class
org.apache.openejb.cluster.server.DefaultEJBClusterManager
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/EJBInvocationProxy.java:[19,25]
cannot resolve symbol
symbol : class InvocationContext
location: package wadi
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/EJBInvocationProxy.java:[21,25]
cannot resolve symbol
symbol : class ProxiedLocation
location: package wadi
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/EJBInvocationProxy.java:[22,25]
cannot resolve symbol
symbol : class ProxyingException
location: package wadi
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/EJBInvocationProxy.java:[30,22]
cannot resolve symbol
symbol : class ProxiedLocation
location: class org.apache.openejb.cluster.server.EJBInvocationProxy
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/EJBInvocationProxy.java:[30,48]
cannot resolve symbol
symbol : class InvocationContext
Re: javamail problems
Dain Sundstrom wrote:
I have been hacking on JavaMail lately and have run into difficulty
overriding the JavaMail SMTP implementation. In the great wisdom of
Sun Microsystems, the only way to add a new protocol provider to the
JavaMail implementation is have the implementation discover it via a
META-INF/javamail.providers or META-INF/javamail.default.providers in
the class loader. Once your provider has been discovered, you can get
it instantiated by either making it the default provider defined by
the first META-INF/javamail.default.providers found in the class
loader, programatically selecting the provider with
session.getProviders() and session.setProvider(provider), or by
passing in the mail.smtp.class=your.SMTPClass to the
Session.getInstance(properties) method. The third option seems really
cool but the class you specify must be mentioned in a META-INF
providers file otherwise the property is silently ignored.
If Sun had just made the constructor for the javax.mail.Provider class
public, you'd be able add additional providers programatically too...sigh.
This appears to only be an issue if you're using the mail session GBeans
to configure the mail sessions. If the code is directly instantiating
the mail session, then it picks up the context classloader for the
application and can load additional providers. The default is still a
bit dependent on search order within the classloaders, however.
I'd like to propose a couple of changes for the next release after 1.2
which should make JavaMail (and some other lame specs) easier to use.
1) Add the ability to declare additional dependencies to the
configuration via the config.xml file. We probably want a way to
exclude a dependency and maybe add to the front of the dependency list
(unless remove re-add works). This is required to add a new provider
to the existing javamail configuration. Without this, you must update
every application to point to a new configuration that contains your
provider jar.
2) Add a className attribute to
org.apache.geronimo.mail.ProtocolGBean and all subclasses. If this is
set then, in addOverrides, we add a
mail.${protocol}.class=${className} to the properties object. There
is no reason to add this until item 1 is complete, since you can't
extend the class path, and would be very confusing to users.
The combination of the 2 sounds reasonable. 2) could be useful without
1), if you're hand constructing your own mail configuration, so it might
be worth adding now.
What do you think?
-dain
Re: AMQ SNAPSHOT download link is still not working
Its back now I think. (Hardware failure at Apache the cause) On 10/24/06, Dhawan, Vikram (LNG-DAY) [EMAIL PROTECTED] wrote: Any one has any idea why people.apache.org is giving a Gateway timeout error when I am trying to click on the latest SNAPSHOT download link? Thanks! Vik -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (AMQ-826) LDAP based authorization support
[ https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_37285 ] james strachan commented on AMQ-826: Note that * is only allowed on a complete path, not regex. So STOCKS.PRICE.NYSE.* or STOCKS.PRICE.*.IBM but not STOCKS.PRICE.NYSE.*BM Thanks for the clarification on union v intersection. So yes, intersection sounds about right, sorry for my previous confusion :) LDAP based authorization support Key: AMQ-826 URL: https://issues.apache.org/activemq/browse/AMQ-826 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Assigned To: Nikola Goran Cutura Attachments: LdapAuth.zip Patch kindly added by ngcutura - discussion thread... http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- 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-1005) Network of brokers duplicates events
Network of brokers duplicates events Key: AMQ-1005 URL: https://issues.apache.org/activemq/browse/AMQ-1005 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2, 4.0.1 Reporter: Linda Floren Priority: Blocker Attachments: ConduitSubscriptionTest.java, SimpleMessageListener.java I've created a test scenario to reproduce the error: Two brokers A and B run with networkconnectors towards each other with conduitSubscriptions=false. The publisher is connected to broker A. There are n Subscribers with identical filters on each broker. Result: The subscribers on broker B receive each event n times. (The subscribers on broker A work fine). It appears as if the subscriptions are treated as conduit subscriptions in the dispatching process on broker B. I've attached my test. -- 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: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
On 10/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: dblevins Date: Wed Oct 25 20:14:43 2006 New Revision: 467848 URL: http://svn.apache.org/viewvc?view=revrev=467848 Log: Added a finder for locating classes in a classloader that have an annotation or implement an interface Hi Dave, You seem to beat me ;-) Nice! + * + * Copyright (c) 2003 David Blevins. All rights reserved. + * + * Is it intended? Also, I don't see XBean 2.7 and 2.8-SNAPSHOT available in any repo. Should it be deployed again? Guillaume? Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
Unfortunately, xbean-2.7 has been lost this weekend. If still have the full xbean repo on my computer so I will upload it as soon as permissions are fixed. And afaik, there were no xbean-2.8 snapshots uploaded (at least, not by me). On 10/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 10/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: dblevins Date: Wed Oct 25 20:14:43 2006 New Revision: 467848 URL: http://svn.apache.org/viewvc?view=revrev=467848 Log: Added a finder for locating classes in a classloader that have an annotation or implement an interface Hi Dave, You seem to beat me ;-) Nice! + * + * Copyright (c) 2003 David Blevins. All rights reserved. + * + * Is it intended? Also, I don't see XBean 2.7 and 2.8-SNAPSHOT available in any repo. Should it be deployed again? Guillaume? Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl -- Cheers, Guillaume Nodet
Re: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
On 10/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Unfortunately, xbean-2.7 has been lost this weekend. If still have the full xbean repo on my computer so I will upload it as soon as permissions are fixed. And afaik, there were no xbean-2.8 snapshots uploaded (at least, not by me). May I ask for 2.8-SNAPSHOT deploy once, for your OpenEJB fellows? ;-) Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
G currently depends on 2.7-SNAPSHOT of some xbean bits, so I roll'd my xbean workspace back right before the cut of 2.7 and am pushing out 2.7-SNAPSHOTS now. Perms are still whack on the repo, needs to be group apcvs (though something is on on mino weird, as it does not look like I am in apcvs from groups or id, though it looks like I'm there in /etc/group). --jason On Oct 26, 2006, at 3:34 AM, Guillaume Nodet wrote: Unfortunately, xbean-2.7 has been lost this weekend. If still have the full xbean repo on my computer so I will upload it as soon as permissions are fixed. And afaik, there were no xbean-2.8 snapshots uploaded (at least, not by me). On 10/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 10/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: dblevins Date: Wed Oct 25 20:14:43 2006 New Revision: 467848 URL: http://svn.apache.org/viewvc?view=revrev=467848 Log: Added a finder for locating classes in a classloader that have an annotation or implement an interface Hi Dave, You seem to beat me ;-) Nice! + * + * Copyright (c) 2003 David Blevins. All rights reserved. + * + * Is it intended? Also, I don't see XBean 2.7 and 2.8-SNAPSHOT available in any repo. Should it be deployed again? Guillaume? Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl -- Cheers, Guillaume Nodet
Re: svn commit: r467560 - in /geronimo/server/trunk: ./ assemblies/geronimo-boilerplate-j2ee/ configs/system-database/ configs/uddi-jetty/ configs/uddi-jetty/src/plan/ configs/uddi-tomcat/ configs/udd
On 10/25/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: hogstrom Date: Tue Oct 24 21:36:33 2006 New Revision: 467560 URL: http://svn.apache.org/viewvc?view=revrev=467560 Log: Updated configurations to support TranQL move to M2 I've seen a few updates wrt the tranql migration (openejb2 and geronimo). I'd like to do it for OpenEJB 3, too, but can't find it anywhere. What repo is it in? Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
I'd do it.. but trunk does not build: snip [INFO] [INFO] Building XBean :: Classloader [INFO]task-segment: [clean, install] [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/xbean/maven- xbean-plugin/2.7/maven-xbean-plugin-2.7.pom [WARNING] Unable to get resource from repository central (http:// repo1.maven.org/maven2) Downloading: http://repo1.maven.org/maven2/org/apache/xbean/maven- xbean-plugin/2.7/maven-xbean-plugin-2.7.pom [WARNING] Unable to get resource from repository central (http:// repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.xbean ArtifactId: maven-xbean-plugin Version: 2.7 Reason: Unable to download the artifact from any repository org.apache.xbean:maven-xbean-plugin:pom:2.7 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot- repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot- repository) /snip --jason On Oct 26, 2006, at 3:39 AM, Jacek Laskowski wrote: On 10/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Unfortunately, xbean-2.7 has been lost this weekend. If still have the full xbean repo on my computer so I will upload it as soon as permissions are fixed. And afaik, there were no xbean-2.8 snapshots uploaded (at least, not by me). May I ask for 2.8-SNAPSHOT deploy once, for your OpenEJB fellows? ;-) Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
On 10/26/06, Jason Dillon [EMAIL PROTECTED] wrote: I'd do it.. but trunk does not build: I've just built it fine. Don't know what might be wrong for you (knowing you're a m2 guru I don't even attempt to guess what might cause it as these obvious things I could come up with may've already been tested out a couple of times ;-)) Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: activemq-cpp build on linux
That worked - Thanks guys! On 10/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'd suggest removing all the old makefiles before running the ./configure, that will avoid any confusion of makefiles. You shouldn't need to older OSTYPE etc stuff with the new ones. -- Timothy A. Bish [EMAIL PROTECTED] - Original Message - From: Nathan Mittler [EMAIL PROTECTED] Date: Monday, October 23, 2006 2:54 pm Subject: activemq-cpp build on linux To: activemq-dev@geronimo.apache.org I'm stumbling through the new build system on linux ... here's what I did after a fresh check-out ... ./autogen.sh ./configure make -f Makefile The first thing that I noticed was that I have to have the environment variables CONFIG and OSTYPE defined, as it appears to be looking for the makefile-linux-debug.cfg file. Is this expected? It seems that that was how the old makefile worked - I didn't expect that to be used by the new setup. If I define CONFIG=debug and OSTYPE=linux, then I get an error saying that no target all-recursive has been defined: [EMAIL PROTECTED] activemq-cpp]$ make -f Makefile make all-recursive make[1]: Entering directory `/home/nmittler/activemq-cpp-workspace/activemq-cpp' make[1]: *** No rule to make target `all-recursive'. Stop. make[1]: Leaving directory `/home/nmittler/activemq-cpp-workspace/activemq-cpp' make: *** [all] Error 2 ... does anyone have an idea of what I might be doing wrong? Thanks, Nate
Re: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
You probably already have 2.7 artifacts in your local repo. --jason On Oct 26, 2006, at 4:04 AM, Jacek Laskowski wrote: On 10/26/06, Jason Dillon [EMAIL PROTECTED] wrote: I'd do it.. but trunk does not build: I've just built it fine. Don't know what might be wrong for you (knowing you're a m2 guru I don't even attempt to guess what might cause it as these obvious things I could come up with may've already been tested out a couple of times ;-)) Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
But trunk (2.8-SNAPSHOT) should probably use plugin versions from 2.8- SNAPSHOT, not 2.7... --jason On Oct 26, 2006, at 4:04 AM, Jacek Laskowski wrote: On 10/26/06, Jason Dillon [EMAIL PROTECTED] wrote: I'd do it.. but trunk does not build: I've just built it fine. Don't know what might be wrong for you (knowing you're a m2 guru I don't even attempt to guess what might cause it as these obvious things I could come up with may've already been tested out a couple of times ;-)) Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
You can not clean unless you have already build the whole tree. The problems comes from the fact that the maven plugin (which is part of the build) is used in some modules. It works when you install, but not when you clean from a clean repo. On 10/26/06, Jason Dillon [EMAIL PROTECTED] wrote: I'd do it.. but trunk does not build: snip [INFO] [INFO] Building XBean :: Classloader [INFO]task-segment: [clean, install] [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/xbean/maven- xbean-plugin/2.7/maven-xbean-plugin-2.7.pom [WARNING] Unable to get resource from repository central (http:// repo1.maven.org/maven2) Downloading: http://repo1.maven.org/maven2/org/apache/xbean/maven- xbean-plugin/2.7/maven-xbean-plugin-2.7.pom [WARNING] Unable to get resource from repository central (http:// repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.xbean ArtifactId: maven-xbean-plugin Version: 2.7 Reason: Unable to download the artifact from any repository org.apache.xbean:maven-xbean-plugin:pom:2.7 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot- repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot- repository) /snip --jason On Oct 26, 2006, at 3:39 AM, Jacek Laskowski wrote: On 10/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Unfortunately, xbean-2.7 has been lost this weekend. If still have the full xbean repo on my computer so I will upload it as soon as permissions are fixed. And afaik, there were no xbean-2.8 snapshots uploaded (at least, not by me). May I ask for 2.8-SNAPSHOT deploy once, for your OpenEJB fellows? ;-) Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl -- Cheers, Guillaume Nodet
Re: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
Nope, the problem is that xbean-classloader depends on maven-xbean-
plugin v2.7 which got lost. It should depend on ${pom.version} so
that it picks up the version built in the current build cycle.
--jason
On Oct 26, 2006, at 4:14 AM, Guillaume Nodet wrote:
You can not clean unless you have already build the whole tree.
The problems comes from the fact that the maven plugin
(which is part of the build) is used in some modules. It works
when you install, but not when you clean from a clean repo.
On 10/26/06, Jason Dillon [EMAIL PROTECTED] wrote:
I'd do it.. but trunk does not build:
snip
[INFO]
-
---
[INFO] Building XBean :: Classloader
[INFO]task-segment: [clean, install]
[INFO]
-
---
Downloading: http://repo1.maven.org/maven2/org/apache/xbean/maven-
xbean-plugin/2.7/maven-xbean-plugin-2.7.pom
[WARNING] Unable to get resource from repository central (http://
repo1.maven.org/maven2)
Downloading: http://repo1.maven.org/maven2/org/apache/xbean/maven-
xbean-plugin/2.7/maven-xbean-plugin-2.7.pom
[WARNING] Unable to get resource from repository central (http://
repo1.maven.org/maven2)
[INFO]
-
---
[ERROR] BUILD ERROR
[INFO]
-
---
[INFO] Failed to resolve artifact.
GroupId: org.apache.xbean
ArtifactId: maven-xbean-plugin
Version: 2.7
Reason: Unable to download the artifact from any repository
org.apache.xbean:maven-xbean-plugin:pom:2.7
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
apache.snapshots (http://people.apache.org/repo/m2-snapshot-
repository),
apache-snapshots (http://people.apache.org/repo/m2-snapshot-
repository)
/snip
--jason
On Oct 26, 2006, at 3:39 AM, Jacek Laskowski wrote:
On 10/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Unfortunately, xbean-2.7 has been lost this weekend.
If still have the full xbean repo on my computer so I will
upload it as soon as permissions are fixed.
And afaik, there were no xbean-2.8 snapshots uploaded
(at least, not by me).
May I ask for 2.8-SNAPSHOT deploy once, for your OpenEJB
fellows? ;-)
Jacek
--
Jacek Laskowski
http://www.jaceklaskowski.pl
--
Cheers,
Guillaume Nodet
Re: svn commit: r467848 - in /geronimo/xbean/trunk/xbean-finder/src: main/java/org/apache/xbean/finder/ test/java/org/acme/foo/ test/java/org/apache/xbean/finder/
I guess the problem comes from the maven release plugin
that does not support that. So it failed to update the
plugin version to 2.8-SNAPSHOT.
On 10/26/06, Jason Dillon [EMAIL PROTECTED] wrote:
Nope, the problem is that xbean-classloader depends on maven-xbean-
plugin v2.7 which got lost. It should depend on ${pom.version} so
that it picks up the version built in the current build cycle.
--jason
On Oct 26, 2006, at 4:14 AM, Guillaume Nodet wrote:
You can not clean unless you have already build the whole tree.
The problems comes from the fact that the maven plugin
(which is part of the build) is used in some modules. It works
when you install, but not when you clean from a clean repo.
On 10/26/06, Jason Dillon [EMAIL PROTECTED] wrote:
I'd do it.. but trunk does not build:
snip
[INFO]
-
---
[INFO] Building XBean :: Classloader
[INFO]task-segment: [clean, install]
[INFO]
-
---
Downloading: http://repo1.maven.org/maven2/org/apache/xbean/maven-
xbean-plugin/2.7/maven-xbean-plugin-2.7.pom
[WARNING] Unable to get resource from repository central (http://
repo1.maven.org/maven2)
Downloading: http://repo1.maven.org/maven2/org/apache/xbean/maven-
xbean-plugin/2.7/maven-xbean-plugin-2.7.pom
[WARNING] Unable to get resource from repository central (http://
repo1.maven.org/maven2)
[INFO]
-
---
[ERROR] BUILD ERROR
[INFO]
-
---
[INFO] Failed to resolve artifact.
GroupId: org.apache.xbean
ArtifactId: maven-xbean-plugin
Version: 2.7
Reason: Unable to download the artifact from any repository
org.apache.xbean:maven-xbean-plugin:pom:2.7
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
apache.snapshots (http://people.apache.org/repo/m2-snapshot-
repository),
apache-snapshots (http://people.apache.org/repo/m2-snapshot-
repository)
/snip
--jason
On Oct 26, 2006, at 3:39 AM, Jacek Laskowski wrote:
On 10/26/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Unfortunately, xbean-2.7 has been lost this weekend.
If still have the full xbean repo on my computer so I will
upload it as soon as permissions are fixed.
And afaik, there were no xbean-2.8 snapshots uploaded
(at least, not by me).
May I ask for 2.8-SNAPSHOT deploy once, for your OpenEJB
fellows? ;-)
Jacek
--
Jacek Laskowski
http://www.jaceklaskowski.pl
--
Cheers,
Guillaume Nodet
--
Cheers,
Guillaume Nodet
G 1.1.2 and 1.1.x
Is there a specific target date for 1.1.2 and other 1.1.x releases? There are 45 JIRAs scheduled for 1.1.2 and 48 for 1.1.x. I do not see much activity on branches\1.1 . Vamsi
Re: J2EE Management for JEE 5
The Stats interfaces are not mandatory. but all the Managed objects as per JSR77.3 are. JSR77.3 reads :"This chapter contains the models and metamodels that specify the format,semantics and relationship of the managed objects required by all compliantimplementations of this specification." I think that according to this the Servlet would be a required Managed objects. But the tomcat version of G is certified without this. What does compliance really mean? If J2EEDeployedObject was missing, would tck complain? ThanksAnita"Christopher M. Cardona" [EMAIL PROTECTED] wrote: Anita,I agree it would be nice to have these statistic interfaces implemented so we can provide performance data. Im not sure if this is even required for JEE 5. I assume its not because we didnt implement it for J2EE 1.4. ...I personally wanted to work on the JEE 5 compliance issues first so we can make tiny steps to our JEE 5 goals. .Best wishes,chrisanita kulshreshtha wrote: Chris, As you said, there is not much to do in upgrading JSR77 from 1.0 to 1.1. However it would be nice to have some of the missing things implemented in 1.0. We could provide implementation of the following interfaces: EJBStats.java EntityBeanStats.java JCAConnectionPoolStats.java JCAConnectionStats.java JCAStats.java JDBCConnectionPoolStats.java JDBCConnectionStats.java JDBCStats.java JMSConnectionStats.java JMSConsumerStats.java JMSEndpointStats.java JMSProducerStats.java JMSSessionStats.java JMSStats.java JTAStats.java JVMStats.java JavaMailStats.java MessageDrivenBeanStats.java ServletStats.java SessionBeanStats.java StatefulSessionBeanStats.java StatelessSessionBeanStats.java URLStats.java Some of these interfaces might be already implemented. I am aware of JVMStatsImpl. In that case we should enable the 'stastisticsProvider' attribute of the ManagedObject. Thanks, Anita */"Christopher M. Cardona" <[EMAIL PROTECTED]>/* wrote: Im currently investigating what it would take to update our J2EE Management (JSR 77) implementation for compliance with JEE 5 in Geronimo. Looking at the changes between spec releases 1.0 (June 18, 2002) and 1.1 (June 22, 2006) there are 4 items that changed: 1. JSR77.4.2.1.3 will be/ changed from "sequence" to/ "sequenceNumber" - This is just a typo error change. 2. JSR77.3.5.0.1 the deploymentDescriptor attribute must provide a full deployment descriptor based on any partial deployment descriptor plus deployment annotations. 3. JSR77.9.1 J2EE Management CIM. The Managed Object Format (MOF) and UML representation of the model are available from the Distributed Management Task Force (DMTF) web site: http://www.dmtf.org/standards/cim 4. JSR77.9.6 Appendix (CIM - Common Information Model) pages 190-214 removed Heres the link to the spec change log: http://jcp.org/aboutJava/communityprocess/maintenance/jsr077/JSR77_MR.html My first question is do we even have to update our current JSR 77 implementation to become JEE 5 compliant. If the spec changes are all we need to consider then it looks like only item 2 needs some attention since item 1 is just a typo error correction and items 3 and 4 are related to CIM which we didnt implement. Im not even sure if we need to do anything with item 2 like checking for deployment descriptor value. Are there any other changes that I need to consider? Please let me know if I am missing anything. Any suggestions, ideas, and concerns are welcome. Thanks, chris How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. Stay in the know. Pulse on the new Yahoo.com. Check it out.
[jira] Created: (AMQ-1006) RoundRobinDispatchPolicy divides uneven
RoundRobinDispatchPolicy divides uneven --- Key: AMQ-1006 URL: https://issues.apache.org/activemq/browse/AMQ-1006 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: Holger Bruch Priority: Minor Attachments: RoundRobinDispatchPolicyDivide.patch In case that multiple consumers with different message selectors are registered for the same destination, messages are not evenly divided. To reproduce, register 2 consumers for prio 9, one for prio 4. Of 1000 messages with prio 9 both prio 9 consumers should receive 500. Actually, the first consumer gets 667 messages, the second 333. This is caused by the consumer shifting strategy in the RoundRobinDispatchPolicy which rotates consumers, even if they did not match. The attached file contains a testcase illustrating the behavior and a patch for RoundRobinDispatchPolicy, that shifts the first matching consumer instead of the first. -- 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: J2EE Management for JEE 5
I looked at the patch attached to GERONIMO-1701. It does not implement EJBStats as defined in JSR77.6.11. Am I missing something?ThanksAnita"Christopher M. Cardona" [EMAIL PROTECTED] wrote: Anita,...I created an EJBModuleStats for the EJB Server portlet patch I submitted a few months ago. Im not sure if this is even required for JEE 5. All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.
BPEL
Hi everybody, I have only one question to make. There's someone who can explain to me what are, if there are, the differences between PXE and BPE bpel Engines. Thanks Davide -- View this message in context: http://www.nabble.com/BPEL-tf2514159.html#a7011746 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: BPEL
PXE and BPE are two different bpel engines. They have both merged into the Apache Ode project which now provides its own JBI component. See http://incubator.apache.org/ode/ On 10/26/06, davipo [EMAIL PROTECTED] wrote: Hi everybody, I have only one question to make. There's someone who can explain to me what are, if there are, the differences between PXE and BPE bpel Engines. Thanks Davide -- View this message in context: http://www.nabble.com/BPEL-tf2514159.html#a7011746 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
Re: G 1.1.2 and 1.1.x
I'd like to do some work on 1.1.2, but I haven't had a lot of time lately. For my part, I guess the schedule depends on whether I get time before 1.2 looks imminent. :) Thanks, Aaron On 10/26/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Is there a specific target date for 1.1.2 and other 1.1.x releases? There are 45 JIRAs scheduled for 1.1.2 and 48 for 1.1.x. I do not see much activity on branches\1.1 . Vamsi
[jira] Commented: (SM-722) ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when a SOAP invocation contains whitespace nodes
[
https://issues.apache.org/activemq/browse/SM-722?page=comments#action_37286 ]
Renaud Bruyeron commented on SM-722:
Sorry about this mess, I think jira saw something special in the code :)
Here's the code again:
{code:title=org.apache.servicemix.jbi.jaxp.ExtendedXMLStreamReader}
public int nextTag() throws XMLStreamException {
int eventType = next();
while((eventType == XMLStreamConstants.CHARACTERS isWhiteSpace())
// skip whitespace
|| (eventType == XMLStreamConstants.CDATA isWhiteSpace())
// skip whitespace
|| eventType == XMLStreamConstants.SPACE
|| eventType == XMLStreamConstants.PROCESSING_INSTRUCTION
|| eventType == XMLStreamConstants.COMMENT
) {
eventType = next();
}
if (eventType != XMLStreamConstants.START_ELEMENT eventType !=
XMLStreamConstants.END_ELEMENT) {
throw new XMLStreamException(expected start or end tag,
getLocation());
}
return eventType;
}
{code}
ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when
a SOAP invocation contains whitespace nodes
-
Key: SM-722
URL: https://issues.apache.org/activemq/browse/SM-722
Project: ServiceMix
Issue Type: Bug
Components: servicemix-core
Affects Versions: 3.0
Reporter: Renaud Bruyeron
Fix For: 3.0.1
The problem is in the code below in ExtendedXMLStreamReader, which is used by
SoapMarshaler to extract the SOAP message from a http invocation, and put it
in a NormalizedMessage.
I have a SOAP message that has things like this: text /text. The
whitespace is significant, and should not be trimmed, yet the message comes
out as text/.
Is there a reason for explicitely doing this?
public int nextTag() throws XMLStreamException {
int eventType = next();
while((eventType == XMLStreamConstants.CHARACTERS isWhiteSpace())
// skip whitespace
|| (eventType == XMLStreamConstants.CDATA isWhiteSpace())
// skip whitespace
|| eventType == XMLStreamConstants.SPACE
|| eventType == XMLStreamConstants.PROCESSING_INSTRUCTION
|| eventType == XMLStreamConstants.COMMENT
) {
eventType = next();
}
if (eventType != XMLStreamConstants.START_ELEMENT eventType !=
XMLStreamConstants.END_ELEMENT) {
throw new XMLStreamException(expected start or end tag,
getLocation());
}
return eventType;
}
--
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
Northern VA JUG
I had the opportunity to speak at the Northern Virginia JUG on Tuesday night and thought I'd share the feedback. The meeting was hosted by a mid-size IT company in Reston, VA. The meeting organizers did a great job of setting things up and provided an excellent facility, refreshments, etc. There were about 20 people in attendance and though not a huge crowd they were very interactive and stumped me a few times with their perceptive questions (ok I admit that's not so difficult). They were already very familiar with the subject matter -- J2EE, ASF, open source application servers, etc. and used the technologies in their daily jobs. So we focused primarily on what is unique about Geronimo - gbean kernel, plugins, admin console, - and where Geronimo is headed over the next few releases. Like I said, they posed some great questions, summarized below: - When is JEE5 support coming? - What is XBean and how does it compare to Spring and GBean? When and how will it be integrated into Geronimo? What does the 'X' in 'XBean' stand for (I just stood there blushing on the last one ;-) - Several detailed questions about how the plugin dependency system works and the other mechanics of plugins and plugin repositories - What maven plugins does Geronimo provide and does Geronimo provide any ant tasks for deployment, etc? - One person had tried to build trunk last month so he could contribute a JACC module but gave up after a couple days of problems with maven. I told him the build is in MUCH better shape now and to try again. - Just how customizable is the server? For example, someone asked how to go about swapping activemq with websphere mq. - Besides the licensing terms, what truly sets Geronimo apart from jboss and glassfish? - What is IBM's interest in Geronimo and how are other companies such as Oracle, BEA, and Sun positioned in this space? They meet twice a month and expressed some interest in hosting a follow up meeting on xbean if possible. Best wishes, Paul
Re: Old activemq and activecluster
Jason Dillon wrote: And it looks like the upgrade from wadi 2.0m1 to 2.0m2-SNAPSHOT is non-trivial. I see a ton of org.codehaus.wadi.gridstate related symbols missing and a bunch of things like missing ProxiedLocation and InvocationContext. I think someone who knows all this wadi muck is going to need to look at this. muck ! :-) Jason, Gianny will know about the finer points of this. I think that you are probably seeing the fallout of (1) refactoring between m1 and m2 and (2) the large WADI dependency tree... (1) provided that external interfaces (or those used by gbean/spring assemblies), internal api changes should not affect you. I'm not sure of the details of Gianny's integration, but if these changes have impacted it, then he will need to update it. (2) The reason for the large number of dependencies is WADI's pluggability. The dependency tree pulls in all of the s/w with which WADI integrates, including AC/AMQ. However, the Geronimo integration will only require a small subset of these deps to run. You'll need to check with Gianny, but I believe that AC/AMQ is one of the dependencies that can be pruned in this way... - If you are pulling all this together via maven2, then you will want a large exclusions element in your WADI dependency. I hope this helps and does not muddy the water too much. If you need more specifics, like which deps are actually required, Gianny and I could put you together a list... just shout. Jules We need to get this resolved so we don't ship different versions of activemq/activeio/activecluster junk with G. --jason On Oct 25, 2006, at 6:11 PM, Jason Dillon wrote: Blah... wadi needs to be upgraded as well :-( --jason On Oct 25, 2006, at 5:27 PM, Dain Sundstrom wrote: Submit a patch. -dain On Oct 25, 2006, at 5:21 PM, Jason Dillon wrote: Looks like openejb2 is still using old ActiveMQ jars. Can we get those deps upgraded plz? --jason On Oct 25, 2006, at 5:11 PM, Jason Dillon wrote: Anyone know why we are still seeing old activemq and activecluster bits? snip [WARNING] POM for 'activecluster:activecluster:pom:1.1- SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM. [WARNING] POM for 'activemq:activemq:pom:3.2.4-SNAPSHOT:compile' is invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 POM. /snip --jason
Re: Old activemq and activecluster
Ok,
I see where you are coming from...
I think that Gianny will have to field this one - I have bcc-ed him. He
is the man on the OpenEJB and Jetty/Geronimo integrations.
Over to you Gianny.
Jules
Jason Dillon wrote:
This is for OpenEJB2, its got a few classes that use WADI 2.0m1 bits
which in turn use old/m1 active{io|mq|cluster} deps. I upgraded the
active{io|mq|cluster} deps and fixed a few imports to use org.apache.*,
but I seem problems building as no org.activecluster classes are on the
CP (they are org.apache.activecluster).
I checked if WADI's trunk was using these but its using the new deps,
so I went to upgrade the WADI deps in OpenEJB2 and then ran into a ton
of compile errors... so I gave up :-(
I could certainly exclude the old active{io|mq|cluster} in G... which
may or may not work, but I would rather have all of the deps in sync...
otherwise I imagine some very strange errors may pop up.
With OpenEJB2 using latest active{io|mq|cluster} and wadi snaps the
openejb-core module pukes out:
snip
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBContainerMonitor.java:
[23,35] package org.codehaus.wadi.gridstate does not exist
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBContainerMonitor.java:
[32,18] cannot resolve symbol
symbol : class Dispatcher
location: class
org.apache.openejb.cluster.server.DefaultEJBContainerMonitor
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBContainerMonitor.java:
[34,38] cannot resolve symbol
symbol : class Dispatcher
location: class
org.apache.openejb.cluster.server.DefaultEJBContainerMonitor
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java: [29,35]
package org.codehaus.wadi.gridstate does not exist
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java: [30,49]
package org.codehaus.wadi.gridstate.activecluster does not exist
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java: [31,40]
package org.codehaus.wadi.gridstate.impl does not exist
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java: [35,30]
cannot resolve symbol
symbol : class DistributableAttributesFactory
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java: [36,30]
cannot resolve symbol
symbol : class DistributableSessionFactory
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java: [37,30]
cannot resolve symbol
symbol : class DistributableValueFactory
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java: [39,30]
cannot resolve symbol
symbol : class DummyRouter
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java: [42,30]
cannot resolve symbol
symbol : class SessionToContextPoolAdapter
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java: [47,30]
cannot resolve symbol
symbol : class StandardSessionWrapperFactory
location: package impl
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/DefaultEJBClusterManager.java: [69,18]
cannot resolve symbol
symbol : class Dispatcher
location: class org.apache.openejb.cluster.server.DefaultEJBClusterManager
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/EJBInvocationProxy.java:[19,25]
cannot resolve symbol
symbol : class InvocationContext
location: package wadi
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/EJBInvocationProxy.java:[21,25]
cannot resolve symbol
symbol : class ProxiedLocation
location: package wadi
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/EJBInvocationProxy.java:[22,25]
cannot resolve symbol
symbol : class ProxyingException
location: package wadi
/Users/jason/ws/geronimo/openejb2/modules/openejb-core/src/main/java/
org/apache/openejb/cluster/server/EJBInvocationProxy.java:[30,22]
cannot resolve symbol
symbol : class ProxiedLocation
location: class
Re: J2EE Management for JEE 5
I think I remember saying EJBModuleStats not EJBStats. The initial statistics I wanted to provide for the EJB Server portlet is on the EJBModule level not on the EJB level. This patch can be enhanced by adding EJB stats. Best wishes, chris anita kulshreshtha wrote: I looked at the patch attached to GERONIMO-1701. It does not implement EJBStats as defined in JSR77.6.11. Am I missing something? Thanks Anita */Christopher M. Cardona [EMAIL PROTECTED]/* wrote: Anita, ... I created an EJBModuleStats for the EJB Server portlet patch I submitted a few months ago. I’m not sure if this is even required for JEE 5. All-new Yahoo! Mail http://us.rd.yahoo.com/evt=43256/*http://advision.webevents.yahoo.com/mailbeta- Fire up a more powerful email and get things done faster.
Migration help from JBoss to Geronimo
Hi , I am currently using the Jboss 4 for my enterprise application. Would you please guide me about, what are the changes required for moving my application from Jboss 4 to Geronimo and also provide me the link from where I can get more information about the same. I will be very thankful for the same. Thanking you in advance. Regards Ashish Chauhan
Re: J2EE Management for JEE 5
"Christopher M. Cardona" [EMAIL PROTECTED] wrote: I think I remember saying "EJBModuleStats" not "EJBStats". The initial statistics I wanted to provide for the EJB Server portlet is on the EJBModule level not on the EJB level. This patch can be enhanced by adding EJB stats.Best wishes,chrisanita kulshreshtha wrote: I looked at the patch attached to GERONIMO-1701. It does not implement EJBStats as defined in JSR77.6.11. Am I missing something? Thanks Anita */"Christopher M. Cardona" <[EMAIL PROTECTED]>/* wrote: Anita, ... I created an EJBModuleStats for the EJB Server portlet patch I submitted a few months ago. Im not sure if this is even required for JEE 5.EJBModuleStats is certainly not required by JEE 5 or J2EE 1.4ThanksAnita Stay in the know. Pulse on the new Yahoo.com. Check it out.
Re: J2EE Management for JEE 5
anita kulshreshtha wrote: */Christopher M. Cardona [EMAIL PROTECTED]/* wrote: I think I remember saying EJBModuleStats not EJBStats. The initial statistics I wanted to provide for the EJB Server portlet is on the EJBModule level not on the EJB level. This patch can be enhanced by adding EJB stats. Best wishes, chris anita kulshreshtha wrote: I looked at the patch attached to GERONIMO-1701. It does not implement EJBStats as defined in JSR77.6.11. Am I missing something? Thanks Anita */Christopher M. Cardona /* wrote: Anita, ... I created an EJBModuleStats for the EJB Server portlet patch I submitted a few months ago. I’m not sure if this is even required for JEE 5. EJBModuleStats is certainly not required by JEE 5 or J2EE 1.4 I concur. Best wishes, chris Thanks Anita Stay in the know. Pulse on the new Yahoo.com. Check it out. http://us.rd.yahoo.com/evt=42974/*http://www.yahoo.com/preview
Re: Migration help from JBoss to Geronimo
Ashish, Now *this* I like to hear ;-) You may wish to look at http://cwiki.apache.org/GMOxDOC10/migrating-to-apache-geronimo.html, but its a little out dated. This link will bring you up to date on Geronimo specifically: http://cwiki.apache.org/GMOxDOC11/apache-geronimo-v11-users-guide.html Jeff Ashish Kumar wrote: Hi , I am currently using the Jboss 4 for my enterprise application. Would you please guide me about, what are the changes required for moving my application from Jboss 4 to Geronimo and also provide me the link from where I can get more information about the same. I will be very thankful for the same. Thanking you in advance. Regards Ashish Chauhan
Re: Old activemq and activecluster
Jules Gosnell wrote: (2) The reason for the large number of dependencies is WADI's pluggability. The dependency tree pulls in all of the s/w with which WADI integrates, including AC/AMQ. However, the Geronimo integration will only require a small subset of these deps to run. You'll need to check with Gianny, but I believe that AC/AMQ is one of the dependencies that can be pruned in this way... - If you are pulling all this together via maven2, then you will want a large exclusions element in your WADI dependency. Jules, Why don't you make your pom register most of the dependencies as optional, so it's up to the end user what they want pulled in? Jeff
Re: where's JACC provider implementation?
My apologies for the extremely late response, this appears to have been sent when my mail wasn't really working. On the other hand in April JACC wasn't pluggable and it is now :-) (almost completely, I hope) The default Geronimo JACC provider is in org.apache.geronimo.security.jacc in the GeronimoPolicyConfigurationFactory and PolicyConfigurationGeneric classes. I suspect we should move these into a different package to make it clear they are the JACC provider rather than the infrastructure geronimo provides. If you want to configure the JACC implementation with non-spec information from geronimo plans you will also need to write a builder similar to the o.a.g.security.deployment.GeronimoSecurityBuilderImpl that reads info from its own xml namespace. If the non-spec information is intended to come from a different source (not geronimo plans) you won't need one of these builders. I recently set up a skeleton example of how a JACC provider could be plugged in, http://www.nabble.com/TripleSec-Geronimo-integration- tf2444664.html#a6815690 It would be great to get another working JACC implementation installed, so if you have any questions how to proceed please ask! thanks david jencks On Apr 22, 2006, at 3:44 PM, argyn wrote: i started looking into code in org.apache.geronimo.security.jacc http://geronimo.apache.org/api/org/apache/geronimo/security/jacc/ package-summary.html package. basically, i want to figure out how to plug the custom JACC provider into Geronimo, so i need to look at the existing ones. where's your default jacc provider? thanks, argyn
JSTL dependencies on JSP/EL
JSTL 1.2 is dependent upon a JSP 2.1 web container (this is no great surprise). However, more specifically the Glassfish JSTL implementation is dependent upon a JSP 2.1 implementation and a 2.1 EL implementation as well. So, I'm wondering where we will pick up the JSP support for the various containers. I've seen it mentioned someplace that Jetty 6 would pick up the Glassfish JSP 2.1 implementation. Is this true? I just downloaded Jetty 6.0.1 and it seems that the JSP2.1 jar in lib does include com.sun classes. However, if look under modules/jsp-2.1 there are apache jasper items there (which I presume are from jakarta). Jan/Greg ... could one of you clarify this? If it is Glassfish then I presume there should be no issue with using the Glassfish JSTL library with Jetty6 ... do you agree? I'm having a more difficult time finding information for Tomcat 6.x. There's no download yet and the documentation for tomcat 6.x seems like it's still a 5.x version of the doc with just 6.x headers. It still references servlet 2.4 and JSP 2.0 (via Jakarta) rather than servlet 2.5 and JSP 2.1. Does anybody (Jeff?) know if Tomcat is planning to pick up the Glassfish JSP 2.1 impl as well or is there going to be a new Jakarta Jasper implementation? Thanks, Joe
Re: Adding a new repo for artifacts
Thanks Anita. I decided that I couldn't pursue this much more without first getting the JSP 2.1 implementation included that JSTL 1.2 depends upon and building Geronimo with a 1.5 JDK. I did experiment with just slamming the JSTL jar with the Glassfish JAR and running under a 1.5 JVM but even with that I hit problems because the Glassfish JSTL 1.2 requires some of the JSP 2.1 EL classes. Joe anita kulshreshtha wrote: John, The jsp example is probably using javax.servlet specs. What I suggested will work only for console. The pom at jstl groupId at java.net at https://maven-repository.dev.java.net/nonav/repository/jstl/poms/jstl-1.2.pom is project modelVersion4.0.0/modelVersion groupIdjstl/groupId artifactIdjstl/artifactId version1.2/version /project This pom is auto generated.. It will not download any other dependencies. The console should work, because it gets its specs from o.a.g.specs. Thanks Anita */Joe Bohn [EMAIL PROTECTED]/* wrote: anita kulshreshtha wrote: The applications/console/console-standard has a dependency: dependency groupIdjavax.servlet/groupId artifactIdjstl/artifactId /dependency The pom for this at javax.servlet groupId is a real one. It is not necessary to download the other specs. You could try replacing this with : dependency groupIdjstl/groupId artifactIdjstl/artifactId . /dependency Hope this is helpful.. Anita, That is what I was trying to do for both the console and the jsp samples. However, to download this artifact from java.net it was my understanding that I also needed to add the java.net repository into the build and specify the version that I needed to download. To accomplish that I changed the JSTL dependencyManagement in the root pom to this: dependency groupIdjstl/groupId artifactIdjstl/artifactId version1.2/version /dependency And then I added this definition for the repository ... repository idjava.net/id urlhttps://maven-repository.dev.java.net/nonav/repository /url layoutlegacy/layout /repository However, that is what seems to be causing the build to pick up javax\servlet\servlet-api\2.4\servlet-api-2.4.jar from java.net rather than the apache snapshot repo ... which is causing me problems in other areas of the build. I didn't follow your earlier post about the JSTL pom being a fake pom .. but my problem so far isn't with JSTL but rather the servlet-api-2.4 jar. BTW, I was doing all of this while keeping the references in the Web Console and the JSP sample just to verify that that the Glassfish JSTL 1.2 would work on JDK 1.4 so long as the newer functions weren't exploited. My next step would be to remove JSTL from the applications and instead add it to J2EE assemblies. Joe thanks Anita */anita kulshreshtha [EMAIL PROTECTED] [EMAIL PROTECTED]YY=73006y5beta=yesy5beta=yesorder=downsort=datepos=0view=ahead=b/* wrote: The spec jars for G are picked up from o.a.g.specs groupId. The JSTL pom is a fake pom. Hence it should not download anything else. The best thing to do will be to move this jar to a different location (private repo?). thanks Anita */Joe Bohn [EMAIL PROTECTED] [EMAIL PROTECTED]YY=73006y5beta=yesy5beta=yesorder=downsort=datepos=0view=ahead=b/* wrote: It appears that we pick these up in our current build. It's just a matter of where we get them from. I'd like to first get things working by picking up just the jar that I need (JSTL) from java.net and check to see if in fact we are picking up other jars that are not necessary (javax\servlet\servlet-api\2.4\servlet-api-2.4.jar in this case). Joe Get your email and more, right on the new Yahoo.com http://us.rd.yahoo.com/evt=42973/*http://www.yahoo.com/preview Yahoo! Messenger with Voice. Make PC-to-Phone Calls http://us.rd.yahoo.com/mail_us/taglines/postman1/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com to the US (and 30+ countries) for 2¢/min or less. All-new Yahoo! Mail http://us.rd.yahoo.com/evt=43256/*http://advision.webevents.yahoo.com/mailbeta- Fire up a more powerful email and get things done faster.
Re: Adding a new repo for artifacts
Thanks Prasad, I couldn't get my local build back to the position that I was in earlier where it was failing because it was pulling in the wrong servlet-api so I didn't get to determine who was pulling in these transitive dependencies. If I get back to that point and determine who the culprit is then I can experiment with the exclusion mechanism. I may have gotten there by some fluke of a partial build with some modules pulling dependencies from java.net and others pulling dependencies from elsewhere. Thanks for the recommendations. Joe Prasad Kashyap wrote: Joe, I still think the specs from javax are being picked up as a transitive dependency. Our specs should be from o.a.g.specs groupId. Did you try the exclusion mechanism at all ? Cheers Prasad On 10/20/06, Joe Bohn [EMAIL PROTECTED] wrote: anita kulshreshtha wrote: The applications/console/console-standard has a dependency: dependency groupIdjavax.servlet/groupId artifactIdjstl/artifactId /dependency The pom for this at javax.servlet groupId is a real one. It is not necessary to download the other specs. You could try replacing this with : dependency groupIdjstl/groupId artifactIdjstl/artifactId . /dependency Hope this is helpful.. Anita, That is what I was trying to do for both the console and the jsp samples. However, to download this artifact from java.net it was my understanding that I also needed to add the java.net repository into the build and specify the version that I needed to download. To accomplish that I changed the JSTL dependencyManagement in the root pom to this: dependency groupIdjstl/groupId artifactIdjstl/artifactId version1.2/version /dependency And then I added this definition for the repository ... repository idjava.net/id urlhttps://maven-repository.dev.java.net/nonav/repository /url layoutlegacy/layout /repository However, that is what seems to be causing the build to pick up javax\servlet\servlet-api\2.4\servlet-api-2.4.jar from java.net rather than the apache snapshot repo ... which is causing me problems in other areas of the build. I didn't follow your earlier post about the JSTL pom being a fake pom .. but my problem so far isn't with JSTL but rather the servlet-api-2.4 jar. BTW, I was doing all of this while keeping the references in the Web Console and the JSP sample just to verify that that the Glassfish JSTL 1.2 would work on JDK 1.4 so long as the newer functions weren't exploited. My next step would be to remove JSTL from the applications and instead add it to J2EE assemblies. Joe thanks Anita */anita kulshreshtha [EMAIL PROTECTED]/* wrote: The spec jars for G are picked up from o.a.g.specs groupId. The JSTL pom is a fake pom. Hence it should not download anything else. The best thing to do will be to move this jar to a different location (private repo?). thanks Anita */Joe Bohn [EMAIL PROTECTED]/* wrote: It appears that we pick these up in our current build. It's just a matter of where we get them from. I'd like to first get things working by picking up just the jar that I need (JSTL) from java.net and check to see if in fact we are picking up other jars that are not necessary (javax\servlet\servlet-api\2.4\servlet-api-2.4.jar in this case). Joe Get your email and more, right on the new Yahoo.com http://us.rd.yahoo.com/evt=42973/*http://www.yahoo.com/preview Yahoo! Messenger with Voice. Make PC-to-Phone Calls http://us.rd.yahoo.com/mail_us/taglines/postman1/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com to the US (and 30+ countries) for 2¢/min or less.
Jetty config dependency on Clustering
Can somebody please help me understand why the Jetty Config has a hard dependency on the Clustering config? It seems a little odd to me that we can't build a Jetty assembly that doesn't contain support for clustering. With Mico-G I was originally able to install the Jetty plugin that I had created just fine. However, since the addition of this clustering dependency this no longer works. If the dependency stays then we need to build a plugin for the clustering module. Joe
[jira] Commented: (SM-722) ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when a SOAP invocation contains whitespace nodes
[
https://issues.apache.org/activemq/browse/SM-722?page=comments#action_37295 ]
Guillaume Nodet commented on SM-722:
Them the problem may come from the StaxSource class.
The code for the nextTag is good, as it is supposed to skip events to the next
start / end tag.
However, the StaxSource does not send any events for entities, spaces...
It should be easy to fix if you have a simple junit test case.
ExtendedXMLStreamReader strips whitespaces, which breaks servicemix-http when
a SOAP invocation contains whitespace nodes
-
Key: SM-722
URL: https://issues.apache.org/activemq/browse/SM-722
Project: ServiceMix
Issue Type: Bug
Components: servicemix-core
Affects Versions: 3.0
Reporter: Renaud Bruyeron
Fix For: 3.0.1
The problem is in the code below in ExtendedXMLStreamReader, which is used by
SoapMarshaler to extract the SOAP message from a http invocation, and put it
in a NormalizedMessage.
I have a SOAP message that has things like this: text /text. The
whitespace is significant, and should not be trimmed, yet the message comes
out as text/.
Is there a reason for explicitely doing this?
public int nextTag() throws XMLStreamException {
int eventType = next();
while((eventType == XMLStreamConstants.CHARACTERS isWhiteSpace())
// skip whitespace
|| (eventType == XMLStreamConstants.CDATA isWhiteSpace())
// skip whitespace
|| eventType == XMLStreamConstants.SPACE
|| eventType == XMLStreamConstants.PROCESSING_INSTRUCTION
|| eventType == XMLStreamConstants.COMMENT
) {
eventType = next();
}
if (eventType != XMLStreamConstants.START_ELEMENT eventType !=
XMLStreamConstants.END_ELEMENT) {
throw new XMLStreamException(expected start or end tag,
getLocation());
}
return eventType;
}
--
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: JSTL dependencies on JSP/EL
Tomcat 6 is just around the corner, but is pretty easy to build from SVN, three steps, 1. svn co https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/ trunk 2. cd trunk 3. ant download 4. ant It generates all the libraries that you'll need, more answers inline Joe Bohn wrote: JSTL 1.2 is dependent upon a JSP 2.1 web container (this is no great surprise). However, more specifically the Glassfish JSTL implementation is dependent upon a JSP 2.1 implementation and a 2.1 EL implementation as well. So, I'm wondering where we will pick up the JSP support for the various containers. it should come with the container itself. Tomcat 6 will ship with it. We are also hoping to publish the individual JARs to the ASF maven repo, so that they can be utilized independently. I've seen it mentioned someplace that Jetty 6 would pick up the Glassfish JSP 2.1 implementation. Is this true? I just downloaded Jetty 6.0.1 and it seems that the JSP2.1 jar in lib does include com.sun classes. However, if look under modules/jsp-2.1 there are apache jasper items there (which I presume are from jakarta). Jan/Greg ... could one of you clarify this? If it is Glassfish then I presume there should be no issue with using the Glassfish JSTL library with Jetty6 ... do you agree? I'm having a more difficult time finding information for Tomcat 6.x. There's no download yet and the documentation for tomcat 6.x seems like it's still a 5.x version of the doc with just 6.x headers. It still references servlet 2.4 and JSP 2.0 (via Jakarta) rather than servlet 2.5 and JSP 2.1. Does anybody (Jeff?) know if Tomcat is planning to pick up the Glassfish JSP 2.1 impl as well or is there going to be a new Jakarta Jasper implementation? Tomcat doesn't pick it up from Glassfish, it sits in the Tomcat source tree. Filip
geronimo plugins and snapshot artifacts
Thanks to Jason's help the geronimo plugins in 1.2-SNAPSHOT are published in the maven snapshot repository. However, the plugin installer gbean can't install them because filenames for published snapshot artifacts can use a special naming convention. Normally the artifact's filename takes the form: artifactId-majorversion.minorversion-SNAPSHOT.type But for snapshot artifacts it can take the form: artifactId-majorversion.minorversion-timestamp-buildNumber.type The timestamp and buildNumber come from a file called maven-metadata.xml in the artifact's download directory. I created GERONIMO-2521 to update PluginInstallerGbean so it can download snapshot artifacts that use the naming convention described above. There's a patch attached to that JIRA if anyone wants to provide feedback before I commit the change. thanks, Paul
Re: Northern VA JUG
On 10/26/06, Paul McMahan [EMAIL PROTECTED] wrote: Like I said, they posed some great questions, summarized below: - When is JEE5 support coming? - What is XBean and how does it compare to Spring and GBean? When and how will it be integrated into Geronimo? What does the 'X' in 'XBean' stand for (I just stood there blushing on the last one ;-) - Several detailed questions about how the plugin dependency system works and the other mechanics of plugins and plugin repositories - What maven plugins does Geronimo provide and does Geronimo provide any ant tasks for deployment, etc? - One person had tried to build trunk last month so he could contribute a JACC module but gave up after a couple days of problems with maven. I told him the build is in MUCH better shape now and to try again. - Just how customizable is the server? For example, someone asked how to go about swapping activemq with websphere mq. - Besides the licensing terms, what truly sets Geronimo apart from jboss and glassfish? - What is IBM's interest in Geronimo and how are other companies such as Oracle, BEA, and Sun positioned in this space? Will we get answers to these questions, too? It's not fair to share it with people out there and leaving us with questions with no answers ;-) I'm going to speak about Apache Geronimo (that I think will in turn be a chance to speak about ASF, open source and such stuff) at the Warszawa JUG on November 7th and would appreciate any help to show its beauty. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: Declarative Exception Handling in ServiceMix
Where are you on this component? Do you plan on donating the code to the ServiceMix project? I also have a use for such a component, but haven't developed one yet. Regards, Jeff Ralf Wunsch wrote: gnodet wrote: A few questions: * How are the errorHandler and errorHandlerConfig related ? * If I want to handle a given exception specifically, i guess I need to implement a custom errorHandler, right ? * how does the errorHandler plug into the jbi container ? * If i have more than one ErrorHandlerComponent in the flow it should be possible to use one ErrorHandler with different configurations for each ErrorHandlerComponent (e.g. to specify different targets for different types of failed messages). To provide this the configuration for the ErrorHandler has been extracted and assembled in the ErrorHandlerConfig XBean. * In my opinion the error handler hook and the handlers strategy should be separated. I am involved in a migration project (from a commercial EAI solution to open source). In the current EAI system an error handler is always implemented. We want to migrate this solution that is based on a set of database stored rules. I think there can be a lot of error handler strategy implementations. One default handler can be an implementation as discussed before. * At this time i am using my own extension of the JBIContainer. This extension registeres an ErrorEventListener as EventListener by default. I have not found a way to configure event listeners in the deployment descriptor. The ErrorHandler is a attribute of the extended container (the getter/setter methods are using the ErrorEventListerners 'errorHandler' attribute). Best regards, Ralf Wunsch -- View this message in context: http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a7019056 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: geronimo plugins and snapshot artifacts
Cool, I noticed the problem in G 1.1 but never had time to look at it ! Thanks a lot. Should it be backported in G 1.1 branch ? On 10/26/06, Paul McMahan [EMAIL PROTECTED] wrote: Thanks to Jason's help the geronimo plugins in 1.2-SNAPSHOT are published in the maven snapshot repository. However, the plugin installer gbean can't install them because filenames for published snapshot artifacts can use a special naming convention. Normally the artifact's filename takes the form: artifactId-majorversion.minorversion-SNAPSHOT.type But for snapshot artifacts it can take the form: artifactId-majorversion.minorversion-timestamp-buildNumber.type The timestamp and buildNumber come from a file called maven-metadata.xml in the artifact's download directory. I created GERONIMO-2521 to update PluginInstallerGbean so it can download snapshot artifacts that use the naming convention described above. There's a patch attached to that JIRA if anyone wants to provide feedback before I commit the change. thanks, Paul -- Cheers, Guillaume Nodet
Re: Northern VA JUG
On 10/26/06, Jacek Laskowski [EMAIL PROTECTED] wrote: Will we get answers to these questions, too? It's not fair to share it with people out there and leaving us with questions with no answers ;-) Well I could take a stab and probably embarrass myself so instead I'll just point you at Jeff and Bruce's upcoming book -- Professional Apache Geronimo :-) Actually a copy of that book was raffled at the meeting and I was quite envious of the winner. Paul
Re: Jetty config dependency on Clustering
David Jencks wrote: On Oct 26, 2006, at 11:43 AM, Joe Bohn wrote: Can somebody please help me understand why the Jetty Config has a hard dependency on the Clustering config? It seems a little odd to me that we can't build a Jetty assembly that doesn't contain support for clustering. geronimo-clustering just has apis. Without an api or an implementation there isn't going to be any way to have clustering support. Better an api than an implementation. Thanks for the explanation David. I didn't realize this only included the APIs. One more question. Why is it better to create this as its own configuration (and for my purposes it's own plugin) rather than just a jar that is included with the Jetty (and Tomcat?) configuration as a dependency? I might be coming at this from the wrong angle, but I'm thinking that as we expose plugins as building blocks for assemblies (where many plugins are basically configs from our build) then some of these items might be too granular and confuse our users. I could see a user thinking that they didn't need (or want) clustering and then wondering why it is pulled into their image anyway. Thanks, Joe With Mico-G I was originally able to install the Jetty plugin that I had created just fine. However, since the addition of this clustering dependency this no longer works. If the dependency stays then we need to build a plugin for the clustering module. Joe
Re: Jetty config dependency on Clustering
On Oct 26, 2006, at 2:41 PM, Joe Bohn wrote: David Jencks wrote: On Oct 26, 2006, at 11:43 AM, Joe Bohn wrote: Can somebody please help me understand why the Jetty Config has a hard dependency on the Clustering config? It seems a little odd to me that we can't build a Jetty assembly that doesn't contain support for clustering. geronimo-clustering just has apis. Without an api or an implementation there isn't going to be any way to have clustering support. Better an api than an implementation. Thanks for the explanation David. I didn't realize this only included the APIs. One more question. Why is it better to create this as its own configuration (and for my purposes it's own plugin) rather than just a jar that is included with the Jetty (and Tomcat?) configuration as a dependency? I might be coming at this from the wrong angle, but I'm thinking that as we expose plugins as building blocks for assemblies (where many plugins are basically configs from our build) then some of these items might be too granular and confuse our users. I could see a user thinking that they didn't need (or want) clustering and then wondering why it is pulled into their image anyway. Whatever ends up as our clustering interface is hopefully going to be used by both the web container and openejb. As such it needs to be in only one config, not 2 or more. If we decide we'll never have a connector-only server with no web or ejb support we could perhaps include it in j2ee-server. thanks david jencks Thanks, Joe With Mico-G I was originally able to install the Jetty plugin that I had created just fine. However, since the addition of this clustering dependency this no longer works. If the dependency stays then we need to build a plugin for the clustering module. Joe
Triplesec JACC Provider
D. Jencks, Sorry for not contacting you sooner but I'm getting buried with things to do lately. Although I've cleared all the IP for the Triplesec import I still have significant work remaining to actually complete the import. I just wanted to give you some status on where I am in case you're wondering what happened. I'm still very interested in starting on this JACC provider. Perhaps things will clear up within the next week or too. Regards, Alex
Re: Triplesec JACC Provider
Thanks for the ping! I'm also kinda buried but would love to get the triplesec stuff working ASAP. I'm subscribed to the directory list now so should see when it gets imported. thanks david jencks On Oct 26, 2006, at 6:44 PM, Alex Karasulu wrote: D. Jencks, Sorry for not contacting you sooner but I'm getting buried with things to do lately. Although I've cleared all the IP for the Triplesec import I still have significant work remaining to actually complete the import. I just wanted to give you some status on where I am in case you're wondering what happened. I'm still very interested in starting on this JACC provider. Perhaps things will clear up within the next week or too. Regards, Alex
[jira] Created: (AMQ-1008) Stomp support for implict creation of temporary destinations: saves server side resources
Stomp support for implict creation of temporary destinations: saves server side resources - Key: AMQ-1008 URL: https://issues.apache.org/activemq/browse/AMQ-1008 Project: ActiveMQ Issue Type: Improvement Components: Broker Environment: N/A Reporter: Sileshi Kassa It is quite simple to extend the existing Stomp destination header field and AMQ Stomp server to support a prefix for temporary queue and topic as follows: destination: /tempqueue/a /temptopic/b This does not change the protocol since destination is opaque from the protocol point of view. The semantics of it is left to Stomp server implementation. This will save a lot of server resources from being wasted. For instance with RPC over Stomp implementation, it takes two queues: request queue and reply queue. A reply queue should be a temp queue in this case. I have discussed this on both Stomp dev and AMQ user forums. Here is the link: http://www.nabble.com/Implicit-AMQ-Temp-Queue-and-Topic-creation-support-tf2516578.html -- 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-1009) incorrect DequeueCount
incorrect DequeueCount -- Key: AMQ-1009 URL: https://issues.apache.org/activemq/browse/AMQ-1009 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Environment: linux Reporter: Winston Huang i am seeing this through activemq (4.0.1) jmx: Type = Queue Destination = XXX QueueSize = 2751 Name = XXX DequeueCount = 3575 MemoryPercentageUsed = 0 ConsumerCount = 6 MemoryLimit = 9223372036854775807 EnqueueCount = 3575 and after a while, something like this: Destination = XXX QueueSize = 11421 Name = XXX DequeueCount = 8046 MemoryPercentageUsed = 0 ConsumerCount = 6 MemoryLimit = 9223372036854775807 EnqueueCount = 13471 my activemq is started with a clean database and journal. how does the math add up among QueueSize, DequeueCount and EnqueueCount? i thought dequeuecount + queuesize = enqueuecount. in my case, QueueSize looks more correct than the dequeuecount is wrong because my consumers are slower than message producers. more info, when i shutdown my consumers, i see stats like this during one test: Type = Queue Destination = XXX QueueSize = 948 Name = XXX DequeueCount = 4224 ConsumerCount = 0 EnqueueCount = 2722 why is DequeueCount greater than EnqueueCount? (the activemq instance was started from a clean database and journal) -- 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
Maven2 vs. Geronimo Maven2 repository problems
I think we have a major problem with out pseudo Maven2 repository impl wrt how SNAPSHOT artifacts are handled. The real m2 repo code when asked for a SNAPSHOT will consult a list of remote repos, and if matched will download a time-stamped artifact which will resolve to the SNAPSHOT version by metadata. Out pseudo m2 repo code knows nothing about time-stamped artifacts and thus can not resolve an artifact that is not named artifactId-n-SNAPHOT.ext, even though m2 can. This is a major problem when packaging cars, as the m2 build will download and resolve SNAPSHOT artifacts, but G will not since it can not find the time-stamped versions that resolve to the artifactId-n- SNAPHOT.ext which was asked for. I did some experiments to make a thin adapter for the car:package goal to delegate to the real m2 repo API, so that it can find time- stamped SNAPSHOT artifacts, but I still end up with exceptions while packaging due to our repo API not resolving properly. I suspect that our artifact resolver code needs to be changed to make this work, but have yet to test/validate that it works. It also looks like our repo API, or its usage is terribly inefficient, as I see that artifacts are asked for over and over and over... which causes a ton of redundant artifact resolutions... which is why when building a car you see a ton of pom related failures over and over and over for the same artifact. All and all this causing major discontinuity between m2 and G repos when SNAPSHOT artifacts are used... which is causing severe build complications. And in short... I have no idea how to fix this. Seems like we should probably reuse the maven repo code... but our repo code is doing some mysterious things that do no map well the the maven code... like looking in parent configs and such and all that explicit resolution mucky muck. Erg... but then again the maven API is not really sock solid either. I have found that if you create an artifact with artifactId-n- SNAPHOT.ext and then resolve it, the resulting artifact's file is groupId/artifactId/n-timestamp/artifactId-n-timestamp.ext instead of what I had hoped groupId/artifactId/n-SNAPSHOT/artifactId-n- timestamp.ext, but ArtifactRepository.pathOf(artifact) returns groupId/artifactId/n-SNAPSHOT/artifactId-n-SNAPSHOT.ext and so with the combonation of the two we can resolve the actual file. I dunno... this is all pissing me off way to much --jason
