Re: Re: what does a ejb-jar.xml looks like?
Hi Aaron, first i thank you for your advices. Now my answears: I don't know exactly what EJB's are. I only know that they are Enterprise Java Beans. But what they are doing is a little black cloud in my mind. My EAR consists of three JAR's, three WAR's and an application.xml as well as a principle.xml. In one of the JAR's is an ejb-jar.xml. This file consists, as you wrote, of the Beans decided to deploy. This JAR is the only which has to be deployed. The other two are some additional informations... some classes more or less. The versions of J2EE and EJB depends on what geronimo 1.1 requires. I think, that they are not higher than J2EE 1.2 and EJB 1 (i asked my boss, and this is what he is supposing). In association with this and my thinking of solve this problem I suggest that I have to set an URL to the ejb-jar.xml in the contained JAR-file of the EAR. Is this the right approach? If you could tell me the way of setting the ejb-jar.xml-path so, that geronimo doesn't make this error, I would thank you very much! PS: assume that the ejb-jar.xml is contained in the META-INF-directory of MyJAR.jar, which is contained in MyEAR.ear. This is only for better understanding :-). Thanks a lot, mika Well, it sounds like the EAR contains an EJB JAR, or at least, the META-INF/application.xml for the EAR is *saying* that it contains an EJB JAR. That EJB JAR should be a JAR file in the EAR, that contains a file META-INF/ejb-jar.xml file. The format of the ejb-jar.xml file is controlled by the EJB specification. It's a bit different depending on which revision of J2EE and EJB you're targeting. But there are DTDs or XML Schemas that dictate the format for each version. As far as what the content of the ejb-jar.xml file is supposed to be, that depends on what the EJB JAR contains -- there should be entries in ejb-jar.xml for each EJB you want to deploy, for example, in the format dictated by the DTD or Schema. So from here, I have a few questions for you: - Do you know what EJBs are and how to use them? - Do you think your EAR contains an EJB JAR? - Would it help you if I gave you the URLs for the ejb-jar.xml DTDs or Schemas? - If so, do you know which EJB or J2EE spec version you're targeting? Thanks, Aaron -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! Feel free mit GMX DSL! http://www.gmx.net/de/go/dsl
Re: [wadi-dev] Session/clustering API and the web tier
Jules Gosnell wrote: I pressed 'send' without counting to 10 first on the last response. Sorry. No probs - no offence taken. I've obviously done a bad job of explaining myself so far. Is this clearer ? Actually no - I preferred the slightly pissed off version for clarity :-) I actually think we are in agreement.. but don´t realize it. You say that the getExcecutionLocation() style API I suggest leaks clustering concerns into the webtier, but I am not suggesting that general container code calls this API. I am suggesting a that a cluster aware interceptor calls it. This is the GSM intercpetion contract of your last email. But given that interceptors are going to be very tier implementation specific and that Jetty has to write geronimo specific interceptors for security, transactions, then it appears natural to me that the G-jetty module is the natural place for that interceptor to live and we don't need to standardize it's contract. Or is it the existence of the standardized API between interceptor and Policy that you object to? Are your concerns such that you do not think this API can be implemented efficiently? Give me 30minutes and I will post my latest mental picture of how I would like to see the Cluster/Session API. cheers
Re: [wadi-dev] Session/clustering API and the web tier
Greg Wilkins wrote: Jules Gosnell wrote: I pressed 'send' without counting to 10 first on the last response. Sorry. No probs - no offence taken. I've obviously done a bad job of explaining myself so far. Is this clearer ? Actually no - I preferred the slightly pissed off version for clarity :-) I actually think we are in agreement.. but don´t realize it. You say that the getExcecutionLocation() style API I suggest leaks clustering concerns into the webtier, but I am not suggesting that general container code calls this API. I am suggesting a that a cluster aware interceptor calls it. This is the GSM intercpetion contract of your last email. But given that interceptors are going to be very tier implementation specific and that Jetty has to write geronimo specific interceptors for security, transactions, then it appears natural to me that the G-jetty module is the natural place for that interceptor to live and we don't need to standardize it's contract. Or is it the existence of the standardized API between interceptor and Policy that you object to? Are your concerns such that you do not think this API can be implemented efficiently? Give me 30minutes and I will post my latest mental picture of how I would like to see the Cluster/Session API. cheers I see the GSM interceptor as a 'peninsula' of the GSM impl, because it deals with clustering concerns. The point at which it meets Jetty is at the generic interceptor API... - I guess this is one of the bones of contention. Seen this way, the same interceptor code can be shared across all containers (via different interceptor adaptors), rather than duplicated by each container and less of the GSM's API needs to be exposed to the container... Jules -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
Cluster API proposal?
This is my idea of how we could morph the currently proposed session APIs
into a cluster API.
I have created a spot for Cluster meta data - but I have not filled it out much.
The key difference is that the state Map is now indexed by session ID and
context ID.
This allows the state for different contexts within the same session to be on
different
nodes (this is a real requirement) and also means that locking is at context
rather
than meta session level. Note that some implementations may not fully support
this and may just do sessionId+contextId behind the scenes and colocate all
context
states for the same session (and move them as one).
I have also added an async aspect to the API for potentially long operations
such as moving state about the place - again this can be optionally supported.
Also I support the idea of multiple Nodes per server (really useful for testing
and heterogeneous clusters).
// The top level Cluster API - this was the Locator... but let's call a spade a
spade.
interface Cluster
{
// methods to get/set meta data about the cluster
// these signatures here are just a guess... but you get the idea.
int getMaxNodes();
SetNode getKnownNodes();
void setKnownNodes(SetNode nodes);
Node getLocalNode();
// Access sessions in cluster.
MetaSession getMetaSession(String clientID);
Session createMetaSession(String sessionId);
}
// Node API
// was Server - but may have multiple Nodes per server
interface Node
{
String getName();
String[] getAddresses(String protocol);
void setAddresses(String string, String[] strings);
boolean isLocalServer();
boolean isActive();
int getPort(String protocol); // one way to handle the multi nodes per
server
int getPortOffset(); // or this one (add to standard port)
}
// Meta Session - was SessionLocation
interface MetaSession
{
String getSessionId();
void invalidate();
void addEventListener(MetaSessionListener listener);
void removeEventListener(MetaSessionListener listener);
// State API has map per context ID , where a context
// ID might be web:/context or ejb: or random
boolean isStateLocal(String contextId);
Map getState(String contextId); // implies a move local!
void getStateAsync(Object key, String contextId); // async version
Map createState(String contextId);
void releaseState(String contextId); // don't lock whole meta session!
void invalidate(String contextId);
// Locaton / Policy API.
Node getNode(String contextId);
Node getExecutionNode(String contextId);
void getExecutionNodeAsync(Object key, String contextId);
// Don't know if these are too HTTP specific... but we need them
void setPassivationTimeout(long ms, String contextId);
void setInvalidationTimeout(long ms, String contextId);
}
interface MetaSessionListener
{
// callbacks to allow session manager to inspect contents for
// tier specific handling (eg servlet listeners etc.)
void activateState(String sessionId, String contextId, Map state);
void passivateState(String sessionId, String contextId, Map state);
void invalidateState(String sessionId, String contextId, Map state);
// callbacks for async operations
void gotState(Object key, String sessionId, String contextId, Map state);
void executionNode(Object key, String sessionId, String contextId, Node
location);
}
[jira] Assigned: (AMQ-644) create Java Service Wrapper for ActiveMQ
[ https://issues.apache.org/activemq/browse/AMQ-644?page=all ] Joseph Dennis Gapuz reassigned AMQ-644: --- Assign To: Joseph Dennis Gapuz create Java Service Wrapper for ActiveMQ Key: AMQ-644 URL: https://issues.apache.org/activemq/browse/AMQ-644 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Assignee: Joseph Dennis Gapuz Priority: Minor Fix For: 4.1 Attachments: wrapper.conf http://wrapper.tanukisoftware.org/doc/english/introduction.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] Work started: (AMQ-644) create Java Service Wrapper for ActiveMQ
[ https://issues.apache.org/activemq/browse/AMQ-644?page=all ] Work on AMQ-644 started by Joseph Dennis Gapuz create Java Service Wrapper for ActiveMQ Key: AMQ-644 URL: https://issues.apache.org/activemq/browse/AMQ-644 Project: ActiveMQ Type: New Feature Components: Broker Reporter: james strachan Assignee: Joseph Dennis Gapuz Priority: Minor Fix For: 4.1 Attachments: wrapper.conf http://wrapper.tanukisoftware.org/doc/english/introduction.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] Resolved: (GERONIMO-2148) Add javamail 1.4 to geronimo specs.
[ http://issues.apache.org/jira/browse/GERONIMO-2148?page=all ] Rick McGuire resolved GERONIMO-2148. Resolution: Fixed Committed revision 421852. Ageronimo-spec-javamail-1.3.1 Ageronimo-spec-javamail-1.3.1/NOTICE.txt Ageronimo-spec-javamail-1.3.1/LICENSE.txt Ageronimo-spec-javamail-1.3.1/src Ageronimo-spec-javamail-1.3.1/pom.xml Ageronimo-spec-javamail-1.3.1/README.txt Dgeronimo-spec-javamail Ageronimo-spec-javamail-1.4 AM geronimo-spec-javamail-1.4/NOTICE.txt AM geronimo-spec-javamail-1.4/LICENSE.txt Ageronimo-spec-javamail-1.4/src Ageronimo-spec-javamail-1.4/src/test Ageronimo-spec-javamail-1.4/src/test/java Ageronimo-spec-javamail-1.4/src/test/java/javax Ageronimo-spec-javamail-1.4/src/test/java/javax/mail Ageronimo-spec-javamail-1.4/src/test/java/javax/mail/event AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/event/MessageCountEventTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/event/MessageChangedEventTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/event/ConnectionEventTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/event/AllEventTests.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/event/FolderEventTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/event/StoreEventTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/event/TransportEventTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/PasswordAuthenticationTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/SimpleTextMessage.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/URLNameTest.java Ageronimo-spec-javamail-1.4/src/test/java/javax/mail/internet AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/ContentDispositionTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/AllInternetTests.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/MimeUtilityTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/ContentTypeTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/ParameterListTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/NewsAddressTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/HeaderTokenizerTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/InternetHeadersTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/PreencodedMimeBodyPartTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/MimeTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/MailDateFormatTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/MimeMultipartTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/MimeBodyPartTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/MimeMessageTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/internet/InternetAddressTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/TestData.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/SessionTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/SimpleFolder.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/HeaderTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/MessageContextTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/QuotaTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/AllTests.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/FlagsTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/MessagingExceptionTest.java Ageronimo-spec-javamail-1.4/src/test/java/javax/mail/util AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/util/SharedFileInputStreamTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/util/SharedByteArrayInputStreamTest.java AM geronimo-spec-javamail-1.4/src/test/java/javax/mail/util/ByteArrayDataSourceTest.java Ageronimo-spec-javamail-1.4/src/test/resources Ageronimo-spec-javamail-1.4/src/test/resources/test.dat Ageronimo-spec-javamail-1.4/src/main Ageronimo-spec-javamail-1.4/src/main/java Ageronimo-spec-javamail-1.4/src/main/java/org Ageronimo-spec-javamail-1.4/src/main/java/org/apache Ageronimo-spec-javamail-1.4/src/main/java/org/apache/geronimo Ageronimo-spec-javamail-1.4/src/main/java/org/apache/geronimo/mail Ageronimo-spec-javamail-1.4/src/main/java/org/apache/geronimo/mail/handlers AM geronimo-spec-javamail-1.4/src/main/java/org/apache/geronimo/mail/handlers/MultipartHandler.java AM geronimo-spec-javamail-1.4/src/main/java/org/apache/geronimo/mail/handlers/HtmlHandler.java AM
[jira] Resolved: (GERONIMO-2086) Create a 1.4 version of javamail.
[ http://issues.apache.org/jira/browse/GERONIMO-2086?page=all ] Rick McGuire resolved GERONIMO-2086. Resolution: Duplicate Duplicate of GERONIMO-2148. Create a 1.4 version of javamail. - Key: GERONIMO-2086 URL: http://issues.apache.org/jira/browse/GERONIMO-2086 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: mail Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Moving forward to the j2ee 5 support, a 1.4 version of javamail will be required. This would also be nice to have as a installable plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo cluster API suggestion
Filip, sorry - but I missed this post before I sent my own API suggestion. However, I think the good news is that your API view is very much the same as my API view We both start at Cluster and can discover meta data about Nodes. Your Cluster provides a channel/message mechanism that I think would be very useful for cluster coordination. Mine expands about session and state But I don't think these are mutually exclusive and I think the two view can be merged without any significant clashes. cheers
Issues Closed: week of 07-14-2006
Project: Apache Geronimo Status: Resolved, Closed (9 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-2086] Create a 1.4 version of javamail. * [GERONIMO-2148] Add javamail 1.4 to geronimo specs. ** Bug * [GERONIMO-1887] Remove unneeded jars from console WEB-INF/lib directories * [GERONIMO-1596] Repeated interface in JMS connection factory plan causes deployment failure * [GERONIMO-2164] Creating SQL- based security realm fails * [GERONIMO-2125] Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path * [GERONIMO-2173] Fix branches/1.1 (1.1.1-SNAPSHOT) build * [GERONIMO-2171] some portions of a build still look at cvs.apache.org/repository * [GERONIMO-1703] ServerInfo.getBaseDirectory() returns null
[jira] Resolved: (GERONIMO-2147) Remove javamail-transport from Geronimo build and replace with javamail-provider dependency.
[ http://issues.apache.org/jira/browse/GERONIMO-2147?page=all ] Rick McGuire resolved GERONIMO-2147. Resolution: Fixed Committed revision 421872. Massemblies/j2ee-jetty-server/project.xml Massemblies/j2ee-installer/project.xml Massemblies/j2ee-tomcat-server/project.xml Mconfigs/javamail/project.xml Mconfigs/rmi-naming/project.xml Mpom.xml Mmodules/pom.xml Mmodules/mail/project.xml Mmodules/mail/pom.xml Mmodules/upgrade/src/test-data/appclient_dep_1_result.xml Mmodules/upgrade/src/test-data/appclient_dep_1.xml Mmodules/activation/project.xml Mmodules/axis/project.xml Dmodules/javamail-transport Metc/project.properties Remove javamail-transport from Geronimo build and replace with javamail-provider dependency. Key: GERONIMO-2147 URL: http://issues.apache.org/jira/browse/GERONIMO-2147 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: mail Affects Versions: 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.2 Attachments: notrans.diff, notrans2.diff Now that the javamail-provider repository and build is available, it's time to replace the javamail-transport module in the Geronimo code tree with a dependency on the javamail_provider_1.3.1 jar file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
An interesting discovery about CSSBean.
I've been taking some hard looks at all of the places where Geronimo creates/configures ORB instances as part of an effort to enable Geronimo for using the Yoko ORB. As a result, I've made an interesting discovery about how CSSBean is working that might warrant a 1.1.1 bug fix. The first part of the discovery was an issue I raised a couple days ago about CSSBean creating 2 ORB instances where 1 would be sufficient. That change simplified the configuration, and also eliminated one of the two threads that CSSBean is creating. The new discovery is that BOTH of the threads that CSSBean creates are unncessary. The two threads that CSSBean creates merely make a call to orb.run(), assuming that run() somehow started ORB execution, and since it was a blocking call, it needed to work on a separate thread. A reasonable assumption, but that's not the purpose of run() at all! The ORB run() method: This operation blocks the current thread until the ORB has completed the shutdown process, initiated when some thread calls |shutdown|. It may be used by multiple threads which get all notified when the ORB shuts down. run() doesn't start anything up at all, it merely waits until the ORB is destroyed. It is not necessary to call run() to use the ORB as a client, so those two threads don't do anything but sit there and wait for the two ORB instances to be destroyed. They're not necessary for GC purposes, because the CSSBean is holding the references (and in fact, is the code that will eventually issue the destroy() call that will terminate the 2 threads). As part of the Yoko changes, I've been reworking this, but there's a pretty good resource boost to be gained, so it might be worthwhile applying at least the thread removal to the 1.1.1 base. Rick
[jira] Created: (GERONIMO-2191) ?wsdl becomes /?wsdl
?wsdl becomes /?wsdl
Key: GERONIMO-2191
URL: http://issues.apache.org/jira/browse/GERONIMO-2191
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: Tomcat
Affects Versions: 1.1
Environment: Geronimo 1.1, Tomcat version; Sun JDK 1.5_4, OpenSuSE
10.1 alpha 4, 712 MB RAM
Reporter: D. Strauss
Hello,
I had created an EJB webservice endpoint. When using the tomcat version of
Geronimo, I cannot get the WSDL from the endpoint. I mean, when using an
endpoint url like
/services/FxWSEP
you can typically get the WSDL by using
/services/FxWSEP?wsdl
The Jetty version of Geronimo 1.1 seems to work correctly. However, the tomcat
version redirects the query:
/services/FxWSEP?wsdl
becomes
/services/FxWSEP/?wsdl
with some interesting info by Tomcat:
HTTP Status 500 - Could not fetch wsdl!
type Status report
message Could not fetch wsdl!
description The server encountered an internal error (Could not fetch wsdl!)
that prevented it from fulfilling this request.
Apache Tomcat/5.5.15
In the log file, you get this wonderful message:
15:33:45,208 ERROR [TomcatEJBWebServiceContext]
java.lang.IllegalStateException: request must contain a wsdl or WSDL
parameter: {wsdl=[Ljava.lang.String;@1a7c7e7}
Aaron Mulder suggested to give the wsdl param a value. Aaron: it doesn't work ;)
Seems that any requests are redirected. The question is: why? :P And, why is
the Jetty version not affected?
Best regards
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Cluster API proposal?
Cool, thanks for posting this.
While I do believe everything in this API is very useful, I see it as an
extension to the one I created.
My API is only about the cluster, and its meta data, while the API below
is very session oriented.
In a cluster without state replication, most of the methods below would
return null or throw UnsupportedOperationException, hence it would make
it harder to implement, and less useful.
The API below is essentially meta data about session state. I personally
consider this an extension to the Cluster API, or a higher level
component, and bada bim, we are back at SessionAPI :), our favorite topics.
Does this make sense? I was looking for the lowest common denominator,
for what a cluster is, essentially, nothing but a group of VMs.
So what I try to do, is that the group wont be forced to expose session
state, cause if there is no state replication, you couldn't implement
that API.
Because I haven't thought much of the session API, as I do consider that
a higher level component, I haven't yet though of a good way, if there
is one, how that would sit on top of a cluster API. But I do believe
they shouldn't be morphed together, instead of the SessionAPI must know
about nodes and clusters, it would get that from the cluster api,
otalthough i personally believe the session api should only know about
sessions and nothing else, but that is why I am staying out of that
topic :)/ot
Filip
Greg Wilkins wrote:
This is my idea of how we could morph the currently proposed session APIs
into a cluster API
I have created a spot for Cluster meta data - but I have not filled it out much.
The key difference is that the state Map is now indexed by session ID and
context ID.
This allows the state for different contexts within the same session to be on
different
nodes (this is a real requirement) and also means that locking is at context
rather
than meta session level. Note that some implementations may not fully support
this and may just do sessionId+contextId behind the scenes and colocate all context
states for the same session (and move them as one).
I have also added an async aspect to the API for potentially long operations
such as moving state about the place - again this can be optionally supported.
Also I support the idea of multiple Nodes per server (really useful for testing
and heterogeneous clusters).
// The top level Cluster API - this was the Locator... but let's call a spade a
spade.
interface Cluster
{
// methods to get/set meta data about the cluster
// these signatures here are just a guess... but you get the idea.
int getMaxNodes();
SetNode getKnownNodes();
void setKnownNodes(SetNode nodes);
Node getLocalNode();
// Access sessions in cluster.
MetaSession getMetaSession(String clientID);
Session createMetaSession(String sessionId);
}
// Node API
// was Server - but may have multiple Nodes per server
interface Node
{
String getName();
String[] getAddresses(String protocol);
void setAddresses(String string, String[] strings);
boolean isLocalServer();
boolean isActive();
int getPort(String protocol); // one way to handle the multi nodes per
server
int getPortOffset(); // or this one (add to standard port)
}
// Meta Session - was SessionLocation
interface MetaSession
{
String getSessionId();
void invalidate();
void addEventListener(MetaSessionListener listener);
void removeEventListener(MetaSessionListener listener);
// State API has map per context ID , where a context
// ID might be web:/context or ejb: or random
boolean isStateLocal(String contextId);
Map getState(String contextId); // implies a move local!
void getStateAsync(Object key, String contextId); // async version
Map createState(String contextId);
void releaseState(String contextId); // don't lock whole meta session!
void invalidate(String contextId);
// Locaton / Policy API.
Node getNode(String contextId);
Node getExecutionNode(String contextId);
void getExecutionNodeAsync(Object key, String contextId);
// Don't know if these are too HTTP specific... but we need them
void setPassivationTimeout(long ms, String contextId);
void setInvalidationTimeout(long ms, String contextId);
}
interface MetaSessionListener
{
// callbacks to allow session manager to inspect contents for
// tier specific handling (eg servlet listeners etc.)
void activateState(String sessionId, String contextId, Map state);
void passivateState(String sessionId, String contextId, Map state);
void invalidateState(String sessionId, String contextId, Map state);
// callbacks for async operations
void gotState(Object key, String sessionId, String contextId, Map state);
void executionNode(Object key, String sessionId, String contextId, Node
location);
}
[jira] Created: (GERONIMO-2192) Jetty can't handle encoded urls that contain a jsessionid
Jetty can't handle encoded urls that contain a jsessionid - Key: GERONIMO-2192 URL: http://issues.apache.org/jira/browse/GERONIMO-2192 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 1.1 Environment: Geronimo 1.1, Jetty version; Sun JDK 1.5_4, OpenSuSE 10.1, 712 MB RAM Reporter: D. Strauss Priority: Critical Hello, another testing here was to check if a webapp would still be usable when the user blocks any cookies from us. JEE typically uses a cookie named JSESSIONID (I think this is specified somewhere) to identify a user at a web request time. Now, if cookies are blocked, the developers are instructed to encode the urls using the HttpServletResponse.encode() method. Even the JSTL and c:url use this behaviour (fortunately :P). Anyway, today, Jetty had some problems when cookies are blocked. The urls are encoded at request time, so, a url like /register.jspx becomes /register.jspx;jsessionid=long hexadecimal value Using Tomcat, everything works as expected (i.e. the user gets identified as long as he/she uses the session identifier). Jetty, on the other hand, drops the request with a HTTP 404 error telling that it can't find a file named register.jspx;jsessionid=long value. This is, of course, right. However, it's not the expected behaviour. Seems that Jetty can't figure out that this request is encoded ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: New Feature Wednesday
Hey David, I'd like to get this process rolling for 1.1.1-SNAPSHOT and 1.2- SNAPSHOT. Are these builds running on GBuild? Can we get multiple people (not just you) to help maintain this? --kevan On May 10, 2006, at 9:26 AM, David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Latest+Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David
Re: Apache Geronimo promotions @OSCON
Hello Susan, Thanks very much for your email this morning. I appreciate your comments about the Public Relations Committee and our apologies about not reaching out to you earlier about this community building event. I had sent an email to the PRC prior to our similar event held at JavaOne, but should have done so with this event as well. As with JavaOne, this is a community based event with a number of different sponsors intended to generate awareness and increase adoption of Apache Geronimo. We are thrilled to work with the Public Relations Committee on this event ans all future events. If you have any time available either today or perhaps Monday, It would be great we schedule a quick call with myself and our VP of Alliances, Phil Robinson, to discuss this event and the best way for us to communicate with you and help promote the Geronimo community moving forward. Best, Kristin Lukos Kristin Lukos Marketing Manager Virtuas Open Source Solutions, LLC 1200 17th Street, Suite 640 Denver, CO 80202 p.303.260.7300 x706 c.303.910.5924 www.virtuas.com Susan Wu wrote: Hi Kristin: I was recently forwarded your announcement about the Apache Geronimo event you're hosting at OSCON. The Public Relations Committee at the ASF is excited that there are vendors showing a strong interest in working with and promoting Geronimo. We strongly encourage you to work with the ASF in your promotional activities where it relates to Apache projects. There is a dedicated committee (the Public Relations Committee, or PRC) here that is exclusively focused on Apache branding, marketing, and partnership activities. We, the ASF, and Geronimo in particular, will also have a booth at OSCON. It seems like we should be coordinating efforts! From what I understand, Geronimo will have a couple of people present who will be staffing the booth. Perhaps there are resources you can allocate as well. I'd be very interested in speaking with you about this. Best, Susan Apache Public Relations Committee
Re: Should we add large String value support in MapMessage in 4.0.2 ?? re: AMQ-788
Ok. look like there was not too much opposition to backporting this so.. I'll go ahead and do it later today. On 7/11/06, Rob Davies [EMAIL PROTECTED] wrote: +1 - sounds good to me On 11 Jul 2006, at 16:42, Hiram Chirino wrote: Hi Folks. In 4.1 we added a patch that add support of handling large string values ( 32k ) in map messages. See: http://issues.apache.org/activemq/browse/AMQ-788 I just wanted to see if you guys think we should backport that to 4.0.2also? The only down side is that a slight incompatibility in marshaling is introduced. It only affect messages that use string values 8k. With the patch once a string value is 8k, we now use a different marshaling strategy that allow for marshaling String values up to 2 gigs. So if you have = 4.0.1 clients talking to 4.0.2 clients sending map messages with String values 8k then the = 4.0.1 clients may not be able handle the messages from the 4.0.2 clients. I think it's safe enough to add since we did not support large messages anyways in 4.0.1. -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Assigned: (GERONIMO-1695) CORBA for EJB with Local interface only causes NPE
[ http://issues.apache.org/jira/browse/GERONIMO-1695?page=all ] Rick McGuire reassigned GERONIMO-1695: -- Assignee: Rick McGuire CORBA for EJB with Local interface only causes NPE -- Key: GERONIMO-1695 URL: http://issues.apache.org/jira/browse/GERONIMO-1695 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 1.0 Reporter: Aaron Mulder Assigned To: Rick McGuire Priority: Critical Fix For: 1.2, 1.1.1 I have an EJB with a local interface and I tried applying CORBA settings. It blows up during deployment. My guess is that it wants a remote interface to be there, but somehow, the checks in StandardServant:126 are not working and the interface just comes up as null. Caused by: java.lang.NullPointerException at org.openejb.corba.util.Util.getAllInterfaces(Util.java:593) at org.openejb.corba.util.Util.getAllMethods(Util.java:815) at org.openejb.corba.util.Util.iiopMap(Util.java:608) at org.openejb.corba.util.Util.mapOperationToMethod(Util.java:604) at org.openejb.corba.StandardServant.init(StandardServant.java:135) at org.openejb.corba.StandardServant.init(StandardServant.java:116) at org.openejb.corba.Adapter.init(Adapter.java:100) ... 67 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1445) Allow deployment and use of exploded EAR modules
[ http://issues.apache.org/jira/browse/GERONIMO-1445?page=all ] Sachin Patel resolved GERONIMO-1445. Resolution: Fixed Can no longer reproduce this, the problem seems to be fixed. Please verify. Allow deployment and use of exploded EAR modules Key: GERONIMO-1445 URL: http://issues.apache.org/jira/browse/GERONIMO-1445 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, Hot Deploy Dir Affects Versions: 1.0 Environment: Windows XP Reporter: Todd Williams Priority: Critical Fix For: 1.1.1 Attachments: GeronimoTestEar.ear.zip Using the Geronimo 1.0 / Tomcat bundle, placing an exploded WAR into the deploy directory causes it to be picked up and deployed by the hot deployer as expected. However, if I wrap the exploded war with an exploded EAR, Geronimo fails to deploy with the error message : 17:00:50,282 INFO [Hot Deployer] Deploying GeronimoTestEar.ear 17:00:51,494 ERROR [Hot Deployer] Unable to deploy: Module was not a war: GeronimoTestWeb.war org.apache.geronimo.common.DeploymentException: Module was not a war: GeronimoTestWeb.war at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:544) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:226) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:122) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$1c79c440.getDeploymentPlan(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:219) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:59) at java.lang.Thread.run(Thread.java:534) I'll attached a zip that when unzipped contains the exploded hierarchy for the EAR. The application is small, but valid, as it deploys just fine when created as an archived EAR. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2186) Editing of Connection Pools other than Derby from console not working
[ http://issues.apache.org/jira/browse/GERONIMO-2186?page=all ] Paul McMahan updated GERONIMO-2186: --- Patch Info: [Patch Available] Component/s: core (was: console) Assignee: Paul McMahan (was: Donald Woods) Priority: Major (was: Minor) Saving changes to a connection pool where the value of at least one attribute is null triggers a NPE on the background timer thread that rewrites config.xml. Derby connection pools commonly don't require username/password so that triggers the exception. The inability to edit a connection pool after editing a Derby connection pool is misleading because changes to the Derby pool seemed to have worked, but they really triggered the NPE which leads to problems later when the GBeanOverride timer has popped. The attached patch to GBeanOverride checks GBean attribute values for null and uses the null=true when persisting them to config.xml. Editing of Connection Pools other than Derby from console not working - Key: GERONIMO-2186 URL: http://issues.apache.org/jira/browse/GERONIMO-2186 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 1.1 Reporter: Krishnakumar B Assigned To: Paul McMahan Fix For: 1.1.1 Attachments: GERONIMO-2186.patch Editing of connection pools other than Derby is currently not working -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2186) Editing of Connection Pools other than Derby from console not working
[ http://issues.apache.org/jira/browse/GERONIMO-2186?page=all ] Paul McMahan updated GERONIMO-2186: --- Attachment: GERONIMO-2186.patch Editing of Connection Pools other than Derby from console not working - Key: GERONIMO-2186 URL: http://issues.apache.org/jira/browse/GERONIMO-2186 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 1.1 Reporter: Krishnakumar B Assigned To: Paul McMahan Fix For: 1.1.1 Attachments: GERONIMO-2186.patch Editing of connection pools other than Derby is currently not working -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Should we add large String value support in MapMessage in 4.0.2 ?? re: AMQ-788
Great! Must be nearly time to cut a 4.0.2 release :) On 7/14/06, Hiram Chirino [EMAIL PROTECTED] wrote: Ok. look like there was not too much opposition to backporting this so.. I'll go ahead and do it later today. On 7/11/06, Rob Davies [EMAIL PROTECTED] wrote: +1 - sounds good to me On 11 Jul 2006, at 16:42, Hiram Chirino wrote: Hi Folks. In 4.1 we added a patch that add support of handling large string values ( 32k ) in map messages. See: http://issues.apache.org/activemq/browse/AMQ-788 I just wanted to see if you guys think we should backport that to 4.0.2also? The only down side is that a slight incompatibility in marshaling is introduced. It only affect messages that use string values 8k. With the patch once a string value is 8k, we now use a different marshaling strategy that allow for marshaling String values up to 2 gigs. So if you have = 4.0.1 clients talking to 4.0.2 clients sending map messages with String values 8k then the = 4.0.1 clients may not be able handle the messages from the 4.0.2 clients. I think it's safe enough to add since we did not support large messages anyways in 4.0.1. -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
Re: svn commit: r421872 - in /geronimo/trunk: ./ assemblies/j2ee-jetty-server/ assemblies/j2ee-tomcat-server/ assemblies/zzzzj2ee-installer/ configs/javamail/ configs/rmi-naming/ etc/ modules/ modules
Where are the Javamail-1.3 1.2-SNAPSHOT artifacts deployed?
--jason
On Jul 14, 2006, at 4:26 AM, [EMAIL PROTECTED] wrote:
Author: rickmcguire
Date: Fri Jul 14 04:26:41 2006
New Revision: 421872
URL: http://svn.apache.org/viewvc?rev=421872view=rev
Log:
GERONIMO-2147 Remove javamail-transport from Geronimo build and
replace with javamail-provider dependency.
Removed:
geronimo/trunk/modules/javamail-transport/
Modified:
geronimo/trunk/assemblies/j2ee-jetty-server/project.xml
geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml
geronimo/trunk/assemblies/j2ee-installer/project.xml
geronimo/trunk/configs/javamail/project.xml
geronimo/trunk/configs/rmi-naming/project.xml
geronimo/trunk/etc/project.properties
geronimo/trunk/modules/activation/project.xml
geronimo/trunk/modules/axis/project.xml
geronimo/trunk/modules/mail/pom.xml
geronimo/trunk/modules/mail/project.xml
geronimo/trunk/modules/pom.xml
geronimo/trunk/modules/upgrade/src/test-data/appclient_dep_1.xml
geronimo/trunk/modules/upgrade/src/test-data/
appclient_dep_1_result.xml
geronimo/trunk/pom.xml
Modified: geronimo/trunk/assemblies/j2ee-jetty-server/project.xml
URL: http://svn.apache.org/viewvc/geronimo/trunk/assemblies/j2ee-
jetty-server/project.xml?rev=421872r1=421871r2=421872view=diff
==
--- geronimo/trunk/assemblies/j2ee-jetty-server/project.xml (original)
+++ geronimo/trunk/assemblies/j2ee-jetty-server/project.xml Fri Jul
14 04:26:41 2006
@@ -25,7 +25,7 @@
descriptionAn assembly of Geronimo into a J2EE Server using
Jetty as the web container/description
dependencies
-!-- plugin we use --
+!-- plugin we use --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-assembly-plugin/artifactId
@@ -292,7 +292,7 @@
geronimo.assembleinstall/geronimo.assemble
/properties
/dependency
-!-- unpack --
+!-- unpack --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-scripts/artifactId
@@ -359,7 +359,7 @@
geronimo.assemblelibrary/geronimo.assemble
/properties
/dependency
-
+
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-kernel/artifactId
@@ -368,7 +368,7 @@
geronimo.assemblelibrary/geronimo.assemble
/properties
/dependency
-
+
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-system/artifactId
@@ -639,7 +639,7 @@
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-javamail_1.3.1_spec/artifactId
-version${geronimo_spec_javamail_version}/version
+version${geronimo_spec_javamail_13_version}/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
@@ -701,14 +701,14 @@
dependency
groupIdantlr/groupId
artifactIdantlr/artifactId
-version${antlr_version}/version
+version${antlr_version}/version
/dependency
dependency
!--what is using this? --
groupIdasm/groupId
artifactIdasm/artifactId
-version${asm_version}/version
+version${asm_version}/version
/dependency
dependency
@@ -1018,7 +1018,7 @@
/dependency
!-- Specification dependencies to preload into the
repository --
-
+
!-- Geronimo modules to preload into the repository --
dependency
groupIdgeronimo/groupId
Modified: geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml
URL: http://svn.apache.org/viewvc/geronimo/trunk/assemblies/j2ee-
tomcat-server/project.xml?rev=421872r1=421871r2=421872view=diff
==
--- geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml
(original)
+++ geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml Fri
Jul 14 04:26:41 2006
@@ -25,7 +25,7 @@
descriptionAn assembly of Geronimo into a J2EE Server using
Tomcat for the web container/description
dependencies
-!-- plugin we use --
+!-- plugin we use --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-assembly-plugin/artifactId
@@ -292,7 +292,7 @@
geronimo.assembleinstall/geronimo.assemble
/properties
/dependency
-!-- unpack --
+!-- unpack --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-scripts/artifactId
@@ -359,7 +359,7 @@
geronimo.assemblelibrary/geronimo.assemble
/properties
/dependency
-
+
dependency
groupIdgeronimo/groupId
Re: New Feature Wednesday
On Jul 14, 2006, at 6:53 AM, Kevan Miller wrote: Hey David, I'd like to get this process rolling for 1.1.1-SNAPSHOT and 1.2- SNAPSHOT. Are these builds running on GBuild? Can we get multiple people (not just you) to help maintain this? I've got to submit a patch for this. I'll put that together later today. -David --kevan On May 10, 2006, at 9:26 AM, David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Latest+Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David
Re: Upgrading JIRA later today
How did this go? Looks like issues is running 3.6.3-DEV-ASF-#156... does this fix the wiki bits? I don't see the tools plugin or the graph plugin though :-( Are those going to make it in? --jason On Jul 13, 2006, at 8:06 PM, Jeff Turner wrote: Hi, At about 7am UTC: http://www.timeanddate.com/worldclock/fixedtime.html? month=7day=14year=2006hour=17min=0sec=0p1=240 I'd like to upgrade JIRA to 3.6.x This will fix an XSS hole in wiki rendering (currently disabled), fix the bug that led to HTTPS being disabled, and allow us to import the Torque CSV data. --Jeff
[jira] Commented: (GERONIMO-1690) Additional support for Targets passed into JSR88
[ http://issues.apache.org/jira/browse/GERONIMO-1690?page=comments#action_12421172 ] Sachin Patel commented on GERONIMO-1690: I think this is on the 1.1.1 list because of the attached patch which is already committed and so the core of the problem (1) is fixed. I think its ok to move 23 our to a future release. as these I would not consider critical for 1.1.1. Additional support for Targets passed into JSR88 Key: GERONIMO-1690 URL: http://issues.apache.org/jira/browse/GERONIMO-1690 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.2 Attachments: patch.txt From an earlier dev list note... 1) The Target is currently discarded by our JSR-88 code because the Deployer GBean does not accept a Target/ConfigStore as an argument. That needs to be changed, but it should be pretty straightforward. 2) I think the Target name is the full ObjectName of the ConfigStore, which means it would be pretty heinous to type on the command line. Hopefully we can make it just the name= component of the ObjectName or something like that, but that would require some thought about what to do in case of non-unique names. 3) I don't think the Hot Deploy Dir GBean lets you specify a Target, and it probably should take that as a config param. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1690) Additional support for Targets passed into JSR88
[ http://issues.apache.org/jira/browse/GERONIMO-1690?page=all ] Sachin Patel updated GERONIMO-1690: --- Fix Version/s: 1.2 (was: 1.1.1) Additional support for Targets passed into JSR88 Key: GERONIMO-1690 URL: http://issues.apache.org/jira/browse/GERONIMO-1690 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.2 Attachments: patch.txt From an earlier dev list note... 1) The Target is currently discarded by our JSR-88 code because the Deployer GBean does not accept a Target/ConfigStore as an argument. That needs to be changed, but it should be pretty straightforward. 2) I think the Target name is the full ObjectName of the ConfigStore, which means it would be pretty heinous to type on the command line. Hopefully we can make it just the name= component of the ObjectName or something like that, but that would require some thought about what to do in case of non-unique names. 3) I don't think the Hot Deploy Dir GBean lets you specify a Target, and it probably should take that as a config param. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r421872 - in /geronimo/trunk: ./ assemblies/j2ee-jetty-server/ assemblies/j2ee-tomcat-server/ assemblies/zzzzj2ee-installer/ configs/javamail/ configs/rmi-naming/ etc/ modules/ modules
Jason Dillon wrote:
Where are the Javamail-1.3 1.2-SNAPSHOT artifacts deployed?
I'm not sure they are yet. This is the level built if you build the
specs freshly. What's the process of getting the snapshots published?
Rick
--jason
On Jul 14, 2006, at 4:26 AM, [EMAIL PROTECTED] wrote:
Author: rickmcguire
Date: Fri Jul 14 04:26:41 2006
New Revision: 421872
URL: http://svn.apache.org/viewvc?rev=421872view=rev
Log:
GERONIMO-2147 Remove javamail-transport from Geronimo build and
replace with javamail-provider dependency.
Removed:
geronimo/trunk/modules/javamail-transport/
Modified:
geronimo/trunk/assemblies/j2ee-jetty-server/project.xml
geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml
geronimo/trunk/assemblies/j2ee-installer/project.xml
geronimo/trunk/configs/javamail/project.xml
geronimo/trunk/configs/rmi-naming/project.xml
geronimo/trunk/etc/project.properties
geronimo/trunk/modules/activation/project.xml
geronimo/trunk/modules/axis/project.xml
geronimo/trunk/modules/mail/pom.xml
geronimo/trunk/modules/mail/project.xml
geronimo/trunk/modules/pom.xml
geronimo/trunk/modules/upgrade/src/test-data/appclient_dep_1.xml
geronimo/trunk/modules/upgrade/src/test-data/appclient_dep_1_result.xml
geronimo/trunk/pom.xml
Modified: geronimo/trunk/assemblies/j2ee-jetty-server/project.xml
URL:
http://svn.apache.org/viewvc/geronimo/trunk/assemblies/j2ee-jetty-server/project.xml?rev=421872r1=421871r2=421872view=diff
==
--- geronimo/trunk/assemblies/j2ee-jetty-server/project.xml (original)
+++ geronimo/trunk/assemblies/j2ee-jetty-server/project.xml Fri Jul
14 04:26:41 2006
@@ -25,7 +25,7 @@
descriptionAn assembly of Geronimo into a J2EE Server using
Jetty as the web container/description
dependencies
-!-- plugin we use --
+!-- plugin we use --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-assembly-plugin/artifactId
@@ -292,7 +292,7 @@
geronimo.assembleinstall/geronimo.assemble
/properties
/dependency
-!-- unpack --
+!-- unpack --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-scripts/artifactId
@@ -359,7 +359,7 @@
geronimo.assemblelibrary/geronimo.assemble
/properties
/dependency
-
+
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-kernel/artifactId
@@ -368,7 +368,7 @@
geronimo.assemblelibrary/geronimo.assemble
/properties
/dependency
-
+
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-system/artifactId
@@ -639,7 +639,7 @@
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-javamail_1.3.1_spec/artifactId
-version${geronimo_spec_javamail_version}/version
+version${geronimo_spec_javamail_13_version}/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
@@ -701,14 +701,14 @@
dependency
groupIdantlr/groupId
artifactIdantlr/artifactId
-version${antlr_version}/version
+version${antlr_version}/version
/dependency
dependency
!--what is using this? --
groupIdasm/groupId
artifactIdasm/artifactId
-version${asm_version}/version
+version${asm_version}/version
/dependency
dependency
@@ -1018,7 +1018,7 @@
/dependency
!-- Specification dependencies to preload into the
repository --
-
+
!-- Geronimo modules to preload into the repository --
dependency
groupIdgeronimo/groupId
Modified: geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml
URL:
http://svn.apache.org/viewvc/geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml?rev=421872r1=421871r2=421872view=diff
==
--- geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml (original)
+++ geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml Fri Jul
14 04:26:41 2006
@@ -25,7 +25,7 @@
descriptionAn assembly of Geronimo into a J2EE Server using
Tomcat for the web container/description
dependencies
-!-- plugin we use --
+!-- plugin we use --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-assembly-plugin/artifactId
@@ -292,7 +292,7 @@
geronimo.assembleinstall/geronimo.assemble
/properties
/dependency
-!-- unpack --
+!-- unpack --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-scripts/artifactId
@@ -359,7 +359,7 @@
Need help on classloading related problem(What is shared/lib in Apache Geronimo)
Hi, I am trying to install Pluto 1.1 portal server into Geronimo. Till now i am able to get About and Admin portlets working. Both these portlets are part of pluto.war. Now i am facing one classloader related problem when i try to install HelloWorld Portlet in HelloWorld.war (Separate war). Basic Problem - I have A.war and B.war they depend on Class1 which is part of 1.jar. What i want is A.war should create object of Class1 and that object should be accessible to class in B.war so where should i put 1.jar and how should i configure both A.war and B.war so that they will be able to look at this class. Detailed Description - Thing is Pluto portlet has PortalDriverServlet which is controller servlet and is shipped with Pluto.war. When it gets request for HelloWorldportlet it wraps that request in object of RenderRequestImpl.java which is in pluto-container-1.1.0-dev.jar and sets is as request parameter and passes control to HelloWorldPortlet. Now HelloWOrldPortlet uses PlutoServlet.java class for handling request and this is again part of pluto-container-1.1.0-dev.jar. When PlutoServlet tries toget object of RenderRequestImpl.java from request it throws ClassCastException because both of them have different class loader. Till now i tried to 1) Create pluto in repository folder containing pluto-container-1.1.0-dev.jar and add dependencies from both pluto.war and HelloWorldPortlet.war on pluto repository. But in that case i get ClasscastException. 2) I tried copying all jars in Geronimo_Base/lib and removed dependencies but that does not work either 3) I tried copying all jars in Geronimo_Base/repository/geronimo/jars and that does not work. Can you please let me know what is equivalent of shared/lib in Geronimo. Place where i could copy jars used by more than one application Thank You Sunil
Apache Geronimo promotions @OSCON
Hi Kristin: I was recently forwarded your announcement about the Apache Geronimo event you're hosting at OSCON. The Public Relations Committee at the ASF is excited that there are vendors showing a strong interest in working with and promoting Geronimo. We strongly encourage you to work with the ASF in your promotional activities where it relates to Apache projects. There is a dedicated committee (the Public Relations Committee, or PRC) here that is exclusively focused on Apache branding, marketing, and partnership activities. We, the ASF, and Geronimo in particular, will also have a booth at OSCON. It seems like we should be coordinating efforts! From what I understand, Geronimo will have a couple of people present who will be staffing the booth. Perhaps there are resources you can allocate as well. I'd be very interested in speaking with you about this. Best, Susan Apache Public Relations Committee
Re: svn commit: r421872 - in /geronimo/trunk: ./ assemblies/j2ee-jetty-server/ assemblies/j2ee-tomcat-server/ assemblies/zzzzj2ee-installer/ configs/javamail/ configs/rmi-naming/ etc/ modules/ modules
On Jul 14, 2006, at 11:08 AM, Rick McGuire wrote: Jason Dillon wrote: Where are the Javamail-1.3 1.2-SNAPSHOT artifacts deployed? I'm not sure they are yet. This is the level built if you build the specs freshly. What's the process of getting the snapshots published? Dunno... I need to know that too soon to start getting genesis and g 1.2-SNAPSHOTS published w/m2. I'm still kinda confused as to which are the official Apache m1 + m2 repositories. --jason
Re: [M2 build] : Error building application uddi-db on XP
modules\system\src\java\org\apache\geronimo\system\repository\AbstractRepository.java Jason Dillon wrote: Where is the code that spits out ##... ? I did not see that in the plugin... maybe I missed it... or maybe its hiding from me. --jason On Jul 12, 2006, at 7:56 PM, Prasad Kashyap wrote: Comes from the installation of the car with the geronimo-assembly- plugin Cheers Prasad On 7/12/06, Jason Dillon [EMAIL PROTECTED] wrote: Where does this output come from: snip # Installed configuration # id = org.apache.geronimo.configs/online-deployer/1.2-SNAPSHOT/car # location = /Users/jason/ws/apache/geronimo/svkmerge/m2migration/ m2-assemblies/j2ee-tomcat-server/target/archive-tmp/repository/org/ apache/geronimo/configs/online-deployer/1.2-SNAPSHOT/online- deployer-1.2-SNAPSHOT.car /snip ? --jason On Jul 12, 2006, at 1:01 PM, Prasad Kashyap wrote: Used by var/config/config.xml of the assemblies. Cheers Prasad. On 7/12/06, Jason Dillon [EMAIL PROTECTED] wrote: We should merge the properties in configs/pom.xml and m2-assemblies/pom.xml. They are common Where are they used? --jason smime.p7s Description: S/MIME Cryptographic Signature
Re: unzipping the source
I was using both XP's and Win2003's built in ZIP extractor and then I tried WinRAR. They each had trouble with some of the .java files, and in some cases were exhibiting the problem as requiring a password for those files. I thought perhaps I had to be a servicemix developer to access them all, but that didn't make sense too much to me. I got the SVN head last night and I am building it now. It seems to be just fine. -- View this message in context: http://www.nabble.com/unzipping-the-source-tf1940729.html#a5332323 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Updated: (GERONIMO-2131) Installed Configuration message written using System.out.println(..) instead of using the log
[ http://issues.apache.org/jira/browse/GERONIMO-2131?page=all ] Donald Woods updated GERONIMO-2131: --- Fix Version/s: 1.2 (was: 1.x) Assignee: Donald Woods Installed Configuration message written using System.out.println(..) instead of using the log --- Key: GERONIMO-2131 URL: http://issues.apache.org/jira/browse/GERONIMO-2131 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1 Reporter: John Sisson Assigned To: Donald Woods Priority: Trivial Fix For: 1.2 I went to the http://jslap:8080/ page and clicked on the Servlet Examples and LDAP Demo and found that messages were written to system.out when I installed the configurations for those examples. This information should be logged rather than printed to System.out. See output below. D:\reltest\geronimo-1.1bin\geronimo.bat run Using GERONIMO_BASE: D:\reltest\geronimo-1.1 Using GERONIMO_HOME: D:\reltest\geronimo-1.1 Using GERONIMO_TMPDIR: D:\reltest\geronimo-1.1\var\temp Using JRE_HOME:C:\j2sdk1.4.2_10 Booting Geronimo Kernel (in Java 1.4.2_10)... Starting Geronimo Application Server v1.1 [**] 100% 37s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8009 0.0.0.0 Tomcat Connector AJP 8080 0.0.0.0 Tomcat Connector HTTP 8443 0.0.0.0 Tomcat Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-tomcat/1.1/car RAR: geronimo/activemq/1.1/car RAR: geronimo/system-database/1.1/car WAR: geronimo/remote-deploy-tomcat/1.1/car WAR: geronimo/welcome-tomcat/1.1/car Web Applications: http://JSLAP:8080/ http://JSLAP:8080/console http://JSLAP:8080/console-standard http://JSLAP:8080/remote-deploy Geronimo Application Server started # Installed configuration # id = geronimo/servlets-examples-tomcat/1.1-SNAPSHOT/car # location = D:\reltest\geronimo-1.1\repository\geronimo\servlets-examples-tomcat\1.1-SNAPSHOT\servlets-examples-tomcat-1.1-SNAPSH OT.car # Installed configuration # id = geronimo/ldap-demo-tomcat/1.1-SNAPSHOT/car # location = D:\reltest\geronimo-1.1\repository\geronimo\ldap-demo-tomcat\1.1-SNAPSHOT\ldap-demo-tomcat-1.1-SNAPSHOT.car -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Virtual Topics (was Re: Failover topic subscribers)
I think something will need to be done in addConsumer(...). When a consumer subscribes to a queue called ActiveMQ.Virtual.GroupName.TopicName, the Destination is not created until someone sends a message to it. The getDestinations(ActiveMQDestination) method returns nothing for ActiveMQ.Virtual.*.TEST when a producer publishes to a Topic called TEST. Should we override the lazy instantiation of ActiveMQDestinations for consumers with the ActiveMQ.Virtual prefix, or just change the way getDestinations(..) works to get destinations that have not been created? -- View this message in context: http://www.nabble.com/Re%3A-Virtual-Topics-%28was-Re%3A-Failover-topic-subscribers%29-tf1942508.html#a5332644 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: [jira] Updated: (GERONIMO-2131) Installed Configuration message written using System.out.println(..) instead of using the log
Sweet :-) --jason On Jul 14, 2006, at 12:15 PM, Donald Woods (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2131?page=all ] Donald Woods updated GERONIMO-2131: --- Fix Version/s: 1.2 (was: 1.x) Assignee: Donald Woods Installed Configuration message written using System.out.println (..) instead of using the log - -- Key: GERONIMO-2131 URL: http://issues.apache.org/jira/browse/ GERONIMO-2131 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1 Reporter: John Sisson Assigned To: Donald Woods Priority: Trivial Fix For: 1.2 I went to the http://jslap:8080/ page and clicked on the Servlet Examples and LDAP Demo and found that messages were written to system.out when I installed the configurations for those examples. This information should be logged rather than printed to System.out. See output below. D:\reltest\geronimo-1.1bin\geronimo.bat run Using GERONIMO_BASE: D:\reltest\geronimo-1.1 Using GERONIMO_HOME: D:\reltest\geronimo-1.1 Using GERONIMO_TMPDIR: D:\reltest\geronimo-1.1\var\temp Using JRE_HOME:C:\j2sdk1.4.2_10 Booting Geronimo Kernel (in Java 1.4.2_10)... Starting Geronimo Application Server v1.1 [**] 100% 37s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8009 0.0.0.0 Tomcat Connector AJP 8080 0.0.0.0 Tomcat Connector HTTP 8443 0.0.0.0 Tomcat Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-tomcat/1.1/car RAR: geronimo/activemq/1.1/car RAR: geronimo/system-database/1.1/car WAR: geronimo/remote-deploy-tomcat/1.1/car WAR: geronimo/welcome-tomcat/1.1/car Web Applications: http://JSLAP:8080/ http://JSLAP:8080/console http://JSLAP:8080/console-standard http://JSLAP:8080/remote-deploy Geronimo Application Server started # Installed configuration # id = geronimo/servlets-examples-tomcat/1.1-SNAPSHOT/car # location = D:\reltest\geronimo-1.1\repository\geronimo \servlets-examples-tomcat\1.1-SNAPSHOT\servlets-examples- tomcat-1.1-SNAPSH OT.car # Installed configuration # id = geronimo/ldap-demo-tomcat/1.1-SNAPSHOT/car # location = D:\reltest\geronimo-1.1\repository\geronimo\ldap- demo-tomcat\1.1-SNAPSHOT\ldap-demo-tomcat-1.1-SNAPSHOT.car -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira
Re: An interesting discovery about CSSBean.
+1 to make the change (pending tck verification) -dain On Jul 14, 2006, at 5:18 AM, Rick McGuire wrote: I've been taking some hard looks at all of the places where Geronimo creates/configures ORB instances as part of an effort to enable Geronimo for using the Yoko ORB. As a result, I've made an interesting discovery about how CSSBean is working that might warrant a 1.1.1 bug fix. The first part of the discovery was an issue I raised a couple days ago about CSSBean creating 2 ORB instances where 1 would be sufficient. That change simplified the configuration, and also eliminated one of the two threads that CSSBean is creating. The new discovery is that BOTH of the threads that CSSBean creates are unncessary. The two threads that CSSBean creates merely make a call to orb.run(), assuming that run() somehow started ORB execution, and since it was a blocking call, it needed to work on a separate thread. A reasonable assumption, but that's not the purpose of run() at all! The ORB run() method: This operation blocks the current thread until the ORB has completed the shutdown process, initiated when some thread calls |shutdown|. It may be used by multiple threads which get all notified when the ORB shuts down. run() doesn't start anything up at all, it merely waits until the ORB is destroyed. It is not necessary to call run() to use the ORB as a client, so those two threads don't do anything but sit there and wait for the two ORB instances to be destroyed. They're not necessary for GC purposes, because the CSSBean is holding the references (and in fact, is the code that will eventually issue the destroy() call that will terminate the 2 threads). As part of the Yoko changes, I've been reworking this, but there's a pretty good resource boost to be gained, so it might be worthwhile applying at least the thread removal to the 1.1.1 base. Rick
[jira] Commented: (GERONIMO-1524) DB pool portlet should let you select multiple driver JARs
[ http://issues.apache.org/jira/browse/GERONIMO-1524?page=comments#action_12421201 ] Donald Woods commented on GERONIMO-1524: Verified that Geronimo-1524.2.patch can be applied to the latest 1.1.1-SNAPSHOT branch. Verified that the DB Pool Wizard now allows you to select both DB2 jarfiles. DB pool portlet should let you select multiple driver JARs -- Key: GERONIMO-1524 URL: http://issues.apache.org/jira/browse/GERONIMO-1524 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0 Reporter: Aaron Mulder Assigned To: Paul McMahan Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-1524.2.patch, GERONIMO-1524.patch Currently the database pool portlet can handle a driver requiring multiple JARs, but the UI doesn't actually let you select more than one. Some drivers known to need more include DB/2 and MS SQL Server. Perhaps the screen should have a checkbox to reveal another 2 driver selection pick lists (the security realm portlet advanced config screen has an example of revealing extra fields if you check a particular checkbox). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r421872 - in /geronimo/trunk: ./ assemblies/j2ee-jetty-server/ assemblies/j2ee-tomcat-server/ assemblies/zzzzj2ee-installer/ configs/javamail/ configs/rmi-naming/ etc/ modules/ modules
We've been letting the GBuild builds push out the Maven 1 artifacts. I was just working on getting the javamail spec into gbuild, since this is killing the Geronimo 1.2 build. We need some process for getting Maven 2 artifacts deployed. Jason, didn't you have some ideas on how to get that done? Tuscany would like our fixed Commonj spec to be published to a Maven 2 repo... --kevan On Jul 14, 2006, at 2:14 PM, Jason Dillon wrote: On Jul 14, 2006, at 11:08 AM, Rick McGuire wrote: Jason Dillon wrote: Where are the Javamail-1.3 1.2-SNAPSHOT artifacts deployed? I'm not sure they are yet. This is the level built if you build the specs freshly. What's the process of getting the snapshots published? Dunno... I need to know that too soon to start getting genesis and g 1.2-SNAPSHOTS published w/m2. I'm still kinda confused as to which are the official Apache m1 + m2 repositories. --jason
Re: An interesting discovery about CSSBean.
Agreed. --kevan On Jul 14, 2006, at 3:24 PM, Dain Sundstrom wrote: +1 to make the change (pending tck verification) -dain On Jul 14, 2006, at 5:18 AM, Rick McGuire wrote: I've been taking some hard looks at all of the places where Geronimo creates/configures ORB instances as part of an effort to enable Geronimo for using the Yoko ORB. As a result, I've made an interesting discovery about how CSSBean is working that might warrant a 1.1.1 bug fix. The first part of the discovery was an issue I raised a couple days ago about CSSBean creating 2 ORB instances where 1 would be sufficient. That change simplified the configuration, and also eliminated one of the two threads that CSSBean is creating. The new discovery is that BOTH of the threads that CSSBean creates are unncessary. The two threads that CSSBean creates merely make a call to orb.run(), assuming that run() somehow started ORB execution, and since it was a blocking call, it needed to work on a separate thread. A reasonable assumption, but that's not the purpose of run() at all! The ORB run() method: This operation blocks the current thread until the ORB has completed the shutdown process, initiated when some thread calls |shutdown|. It may be used by multiple threads which get all notified when the ORB shuts down. run() doesn't start anything up at all, it merely waits until the ORB is destroyed. It is not necessary to call run() to use the ORB as a client, so those two threads don't do anything but sit there and wait for the two ORB instances to be destroyed. They're not necessary for GC purposes, because the CSSBean is holding the references (and in fact, is the code that will eventually issue the destroy() call that will terminate the 2 threads). As part of the Yoko changes, I've been reworking this, but there's a pretty good resource boost to be gained, so it might be worthwhile applying at least the thread removal to the 1.1.1 base. Rick
Re: Cluster API proposal?
On Jul 14, 2006, at 1:47 AM, Greg Wilkins wrote:
This is my idea of how we could morph the currently proposed
session APIs
into a cluster API.
I have created a spot for Cluster meta data - but I have not filled
it out much.
The key difference is that the state Map is now indexed by session
ID and context ID.
This allows the state for different contexts within the same
session to be on different
nodes (this is a real requirement)
I think I missed some of the discussion. Why is this a requirement?
I know some deployments like to split applications into multiple
tiers, but why would the servlet or ejb containers need to know about
that?
and also means that locking is at context rather
than meta session level. Note that some implementations may not
fully support
this and may just do sessionId+contextId behind the scenes and
colocate all context
states for the same session (and move them as one).
If we assume we are working in an IoC environment, I don't see why
the api would need to explicitly call out support for a context.
Lets say Jetty has a setter for SessionManager, if you want to have a
private context for your jetty data, you can simply have the IoC
layer inject a wrapped version of SessionManager that does the string
append, or if your clustering framework supports the concept of a
context directly, the IoC layer could inject
fooCluster.getPrivateSessionContext(contextId).
This is what I like about the session API. It only contains the apis
needed for someone to get their session data. All complex deployment
decisions or configuration can be pushed to the IoC layer.
I have specific comments about the apis below.
-dain
// The top level Cluster API - this was the Locator... but let's
call a spade a spade.
interface Cluster
{
// methods to get/set meta data about the cluster
// these signatures here are just a guess... but you get the
idea.
int getMaxNodes();
SetNode getKnownNodes();
void setKnownNodes(SetNode nodes);
Node getLocalNode();
// Access sessions in cluster.
MetaSession getMetaSession(String clientID);
Session createMetaSession(String sessionId);
}
I'd prefer we don't call it cluster as it could then concievely
contain anything. The job of this interface is to manage session and
I think we should call it a SessionManager.
// Node API
// was Server - but may have multiple Nodes per server
interface Node
{
String getName();
String[] getAddresses(String protocol);
void setAddresses(String string, String[] strings);
boolean isLocalServer();
boolean isActive();
int getPort(String protocol); // one way to handle the multi
nodes per server
int getPortOffset(); // or this one (add to standard
port)
}
Calling it a Node is cool with me.
I'd drop the port stuff. Ports imply IP and protocols could be P2P
and wouldn't have a port. When James and I wrote this, we expected
addresses to contain a URI, but didn't want to force java.net.URI on
everyone, so we went with String.
// Meta Session - was SessionLocation
interface MetaSession
{
String getSessionId();
void invalidate();
void addEventListener(MetaSessionListener listener);
void removeEventListener(MetaSessionListener listener);
// State API has map per context ID , where a context
// ID might be web:/context or ejb: or random
boolean isStateLocal(String contextId);
Map getState(String contextId); // implies a move local!
void getStateAsync(Object key, String contextId); // async
version
Map createState(String contextId);
void releaseState(String contextId); // don't lock whole meta
session!
void invalidate(String contextId);
// Locaton / Policy API.
Node getNode(String contextId);
Node getExecutionNode(String contextId);
void getExecutionNodeAsync(Object key, String contextId);
// Don't know if these are too HTTP specific... but we need them
void setPassivationTimeout(long ms, String contextId);
void setInvalidationTimeout(long ms, String contextId);
}
As I mentioned above, I don't like the context stuff, but the rest is
good.
I think we should drop the async method until we have some
implementations. Specially, I think it will need an optional
listener parameter so you can be notified when the transfer is complete.
I think the passivation methods are good general purpose items. Do
we need a last modified, or last accessed items also?
interface MetaSessionListener
{
// callbacks to allow session manager to inspect contents for
// tier specific handling (eg servlet listeners etc.)
void activateState(String sessionId, String contextId, Map state);
void passivateState(String sessionId, String contextId, Map
state);
void invalidateState(String sessionId, String contextId, Map
state);
// callbacks for async operations
void
Re: Cluster API proposal?
I think we are starting to agree. I see the session manager as a
high level component that *can* be implemented on top of a cluster or
just be a local hash map. The idea was to create an abstraction such
that, the people writing clustering code can easily plugin into
geronimo services that have session data (which is about the only
pice of cluster data that we have right now).
As for low level Clustering apis, I don't have much of a preference
unless I have to write to them, and the stuff I'm working on can be
completely satisfied by the session api.
-dain
On Jul 14, 2006, at 6:41 AM, Filip Hanik - Dev Lists wrote:
Cool, thanks for posting this.
While I do believe everything in this API is very useful, I see it
as an extension to the one I created.
My API is only about the cluster, and its meta data, while the API
below is very session oriented.
In a cluster without state replication, most of the methods below
would return null or throw UnsupportedOperationException, hence it
would make it harder to implement, and less useful.
The API below is essentially meta data about session state. I
personally consider this an extension to the Cluster API, or a
higher level component, and bada bim, we are back at SessionAPI :),
our favorite topics.
Does this make sense? I was looking for the lowest common
denominator, for what a cluster is, essentially, nothing but a
group of VMs.
So what I try to do, is that the group wont be forced to expose
session state, cause if there is no state replication, you couldn't
implement that API.
Because I haven't thought much of the session API, as I do consider
that a higher level component, I haven't yet though of a good way,
if there is one, how that would sit on top of a cluster API. But I
do believe they shouldn't be morphed together, instead of the
SessionAPI must know about nodes and clusters, it would get that
from the cluster api, otalthough i personally believe the session
api should only know about sessions and nothing else, but that is
why I am staying out of that topic :)/ot
Filip
Greg Wilkins wrote:
This is my idea of how we could morph the currently proposed
session APIs
into a cluster API
I have created a spot for Cluster meta data - but I have not
filled it out much.
The key difference is that the state Map is now indexed by session
ID and context ID.
This allows the state for different contexts within the same
session to be on different
nodes (this is a real requirement) and also means that locking is
at context rather
than meta session level. Note that some implementations may not
fully support this and may just do sessionId+contextId behind the
scenes and colocate all context
states for the same session (and move them as one).
I have also added an async aspect to the API for potentially long
operations
such as moving state about the place - again this can be
optionally supported.
Also I support the idea of multiple Nodes per server (really
useful for testing
and heterogeneous clusters).
// The top level Cluster API - this was the Locator... but let's
call a spade a spade.
interface Cluster
{
// methods to get/set meta data about the cluster
// these signatures here are just a guess... but you get the
idea.
int getMaxNodes();
SetNode getKnownNodes();
void setKnownNodes(SetNode nodes);
Node getLocalNode();
// Access sessions in cluster. MetaSession
getMetaSession(String clientID);
Session createMetaSession(String sessionId);
}
// Node API
// was Server - but may have multiple Nodes per server
interface Node
{
String getName();String[] getAddresses(String
protocol);void setAddresses(String string, String[]
strings);boolean isLocalServer();
boolean isActive();
int getPort(String protocol); // one way to handle the multi
nodes per server
int getPortOffset(); // or this one (add to standard
port)
}
// Meta Session - was SessionLocation
interface MetaSession
{
String getSessionId();
void invalidate();
void addEventListener(MetaSessionListener listener);
void removeEventListener(MetaSessionListener listener);
// State API has map per context ID , where a context
// ID might be web:/context or ejb: or random
boolean isStateLocal(String contextId);
Map getState(String contextId); // implies a move local!
void getStateAsync(Object key, String contextId); // async
version
Map createState(String contextId);
void releaseState(String contextId); // don't lock whole meta
session!
void invalidate(String contextId);
// Locaton / Policy API.
Node getNode(String contextId); Node getExecutionNode
(String contextId); void getExecutionNodeAsync(Object key,
String contextId);
// Don't know if these are too HTTP specific... but we need
them void
[jira] Updated: (GERONIMO-1182) Connector portlet delete challenge
[ http://issues.apache.org/jira/browse/GERONIMO-1182?page=all ] Joe Bohn updated GERONIMO-1182: --- Summary: Connector portlet delete challenge (was: Connector portlet improvement (delete connector confirmation, more form buttons)) Issue Type: Bug (was: Improvement) Fix Version/s: 1.1.1 (was: 1.2) If we consider 1037 (confirmation required on delete of an module) to be a usability bug (which I agree with) then I think we also need to consider this patch for Geronimo 1.1.1. Connector portlet delete challenge --- Key: GERONIMO-1182 URL: http://issues.apache.org/jira/browse/GERONIMO-1182 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1182-1.patch, GERONIMO-1182.patch Minor improvements to Connector portlet. 1. User confirmation on clicking delete link to delete a connector. 2. Add Reset and Cancel buttons to edit pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1492) Many org/apache/geronimo configIds still live in source tree
[ http://issues.apache.org/jira/browse/GERONIMO-1492?page=comments#action_12421213 ] Paul McMahan commented on GERONIMO-1492: The attached patch (GERONIMO-1492-1.patch) removes all org/apache/geronimo configIds found by the grep command specified above. It was created before 1.1 was released so I just rechecked it and verified that it works correctly when applied to both 1.1.1-SNAPSHOT and trunk. To test the patch do the following: - cd to top level geronimo dir - patch -p0 GERONIMO-1492-1.patch - make sure you don't have maven tests disabled - maven -o clean new, all test should pass - start the console and you should no longer see the system-database listed in the started application modules. instead it should say: Started Application Modules: EAR: geronimo/webconsole-tomcat/1.2-SNAPSHOT/car RAR: geronimo/activemq/1.2-SNAPSHOT/car WAR: geronimo/remote-deploy-tomcat/1.2-SNAPSHOT/car WAR: geronimo/welcome-tomcat/1.2-SNAPSHOT/car Many org/apache/geronimo configIds still live in source tree -- Key: GERONIMO-1492 URL: http://issues.apache.org/jira/browse/GERONIMO-1492 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Paul McMahan Priority: Blocker Fix For: 1.1.1 Attachments: annotated-grep-output.txt, GERONIMO-1492-1.patch, GERONIMO-1492.diff I created a couple separate issues, but beyond those a quick search brought up a few more in magic G ball and day trader -- I stopped before it went any further, but we should grep for that and try to eliminate all the references to old-style config IDs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1492) Many org/apache/geronimo configIds still live in source tree
[ http://issues.apache.org/jira/browse/GERONIMO-1492?page=comments#action_12421214 ] Paul McMahan commented on GERONIMO-1492: start the console and you should no longer see the system-database listed in the started application modules. instead it should say: meant to say start the *server* (from the command line) not the console Many org/apache/geronimo configIds still live in source tree -- Key: GERONIMO-1492 URL: http://issues.apache.org/jira/browse/GERONIMO-1492 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Paul McMahan Priority: Blocker Fix For: 1.1.1 Attachments: annotated-grep-output.txt, GERONIMO-1492-1.patch, GERONIMO-1492.diff I created a couple separate issues, but beyond those a quick search brought up a few more in magic G ball and day trader -- I stopped before it went any further, but we should grep for that and try to eliminate all the references to old-style config IDs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Should we add large String value support in MapMessage in 4.0.2 ?? re: AMQ-788
Can we set message timeout in a stomp client in the situations where STOMP client is trying to send a message and because of network issues (FIREWALL or something else) it cant not reach to the AMQ server. So instead of trying to send the message indefinitely STOMP client process will terminate. Thanks! Vik -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Friday, July 14, 2006 1:26 PM To: activemq-dev@geronimo.apache.org Subject: Re: Should we add large String value support in MapMessage in 4.0.2 ?? re: AMQ-788 Great! Must be nearly time to cut a 4.0.2 release :) On 7/14/06, Hiram Chirino [EMAIL PROTECTED] wrote: Ok. look like there was not too much opposition to backporting this so.. I'll go ahead and do it later today. On 7/11/06, Rob Davies [EMAIL PROTECTED] wrote: +1 - sounds good to me On 11 Jul 2006, at 16:42, Hiram Chirino wrote: Hi Folks. In 4.1 we added a patch that add support of handling large string values ( 32k ) in map messages. See: http://issues.apache.org/activemq/browse/AMQ-788 I just wanted to see if you guys think we should backport that to 4.0.2also? The only down side is that a slight incompatibility in marshaling is introduced. It only affect messages that use string values 8k. With the patch once a string value is 8k, we now use a different marshaling strategy that allow for marshaling String values up to 2 gigs. So if you have = 4.0.1 clients talking to 4.0.2 clients sending map messages with String values 8k then the = 4.0.1 clients may not be able handle the messages from the 4.0.2 clients. I think it's safe enough to add since we did not support large messages anyways in 4.0.1. -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (GERONIMO-2188) Need to configure CommitBeforeAutoCommit=true for Database Commits in Oracle
[ http://issues.apache.org/jira/browse/GERONIMO-2188?page=comments#action_12421227 ] Donald Woods commented on GERONIMO-2188: Attaching source email thread from [EMAIL PROTECTED] - Original Message Subject: Re: daytrader with Tranql Oracle XA resource adapter Date: Fri, 7 Jul 2006 09:38:32 -0700 From: David Jencks [EMAIL PROTECTED] Reply-To: user@geronimo.apache.org To: user@geronimo.apache.org References: [EMAIL PROTECTED] Can you (or have you already) try using the generic tranql wrapper with the oracle Driver class and set the commitBeforeAutocommit property to true? This definitely _ought_ to make the commit happen immediately: if it does, the oracle driver has a bug and we need to modify the oracle wrapper to work around it. thanks david jencks On Jul 7, 2006, at 8:25 AM, Lin Sun wrote: Hi there, Thanks for the pointer! IIUC, if the application uses connection.commit, tranql will translate that as setautocommit(true) when the commitBeforeAutoCommit is set to false. I believe this is what I have in my environment. However, I still don't understand why it makes such a big difference for Oracle. I have loaded daytrader on another J2EE application server (WebSphere Application Server) and found out the same order committed to the oracle database right away. With that, I would not categorize it as one of the problematic drivers you mentioned before. Since derby and db2 XA adapter don't have this delayed committing problem at all, I compared the two Tranql vendors' code with the Oracle vendor code. Basically the vendor code contains the vendor specific MCF class that is created based on the datasource from the vendor (for example, OracleXADataSource). The MCF also sets/gets the datasource's different properties (like databasename, username, password, servername, etc.). I still don't get much clue as to why Oracle is special with Tranql. I think what I'll do is to come up with a simple application that can be loaded into Eclipse and step into the connection.commit() code from Eclipse. Too bad that I haven't figured out how to get daytrader running from Eclipse.:-( Time to study the new plugin Sachin puts out.:-) Lin Need to configure CommitBeforeAutoCommit=true for Database Commits in Oracle Key: GERONIMO-2188 URL: http://issues.apache.org/jira/browse/GERONIMO-2188 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1.1 Reporter: Krishnakumar B Assigned To: Donald Woods We have to configure CommitBeforeAutCommit=true property exclusively in the database connection pool plan, to have the ejb -based transactions immediately committed for oracle database. Otherwise it only commits transaction when the server shuts-down. This problem is not faces with Derby database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: build.xml example
Rafael, are you wanting to use Ant to run the Geronimo build, start/stop Geronimo, deploy apps into Geronimo, ...? I have a working sample of the first (starting Geronimo build from Ant). -Donald Aaron Mulder wrote: What kind of application are you working on? (e.g. WAR, EAR, EJBs, etc.) I can probably sketch some steps that your build should take, though I don't have a specific Ant/Geronimo example (I've used Maven for all my Geronimo-related builds). Thanks, Aaron On 7/13/06, Rafael Barrera Oro [EMAIL PROTECTED] wrote: Im sorry, but i 've been unable to find out what a build.xml example for using ant with geronimo looks like, so i ask you guys. As usual, thanks in advance Rafael smime.p7s Description: S/MIME Cryptographic Signature
[m2 build] Update about custom assembly usage
It looks like the Maven 2 peeps are not going to be able to take in our patches to apply to the assembly plugin, which provides mappers and some includes/excludes to unpack and a permission related fix to files/file element processing. I believe that those changes will eventually make it in, but for now to get around the need Prasad and I talked about using the dependency plugin and the antrun plugin to perform the needed flattening of the schema files for the /schema/* in the assembly. I've implemented this already for the geronimo-jetty-j2ee assembly in the svkmerge/m2migration branch. It appears to function as expected. I've disabled the remaining assemblies which have not yet been converted. Once they have been converted they will be re-enabled. Note, we are still using car:installConfigs... but we no longer need to have MASSEMBLY-45 or MASSEMBLY-127 applied to a custom 2.2- SNAPSHOT version of the maven-assembly-plugin to build out assemblies. The full conversation is here if anyone is interested: http://uwyn.com/drone/log/bevinbot/geronimo/20060714 Starts with '19:53 jdillon any thoughts on using dependency + antrun to setup the right bits and then use the 2.1 assembly plugin?' --jason
Re: svn commit: r421872 - in /geronimo/trunk: ./ assemblies/j2ee-jetty-server/ assemblies/j2ee-tomcat-server/ assemblies/zzzzj2ee-installer/ configs/javamail/ configs/rmi-naming/ etc/ modules/ modules
I have not had a chance to look into this more. I'm going to ping repository@ and see what the current official locations are for m2 artifacts (release + snapshot + sync to central). --jason On Jul 14, 2006, at 12:33 PM, Kevan Miller wrote: We've been letting the GBuild builds push out the Maven 1 artifacts. I was just working on getting the javamail spec into gbuild, since this is killing the Geronimo 1.2 build. We need some process for getting Maven 2 artifacts deployed. Jason, didn't you have some ideas on how to get that done? Tuscany would like our fixed Commonj spec to be published to a Maven 2 repo... --kevan On Jul 14, 2006, at 2:14 PM, Jason Dillon wrote: On Jul 14, 2006, at 11:08 AM, Rick McGuire wrote: Jason Dillon wrote: Where are the Javamail-1.3 1.2-SNAPSHOT artifacts deployed? I'm not sure they are yet. This is the level built if you build the specs freshly. What's the process of getting the snapshots published? Dunno... I need to know that too soon to start getting genesis and g 1.2-SNAPSHOTS published w/m2. I'm still kinda confused as to which are the official Apache m1 + m2 repositories. --jason
[jira] Created: (XBEAN-24) [RTC] Support mixed nested properties and complex elements
[RTC] Support mixed nested properties and complex elements
--
Key: XBEAN-24
URL: http://issues.apache.org/jira/browse/XBEAN-24
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Dain Sundstrom
Assigned To: Dain Sundstrom
Priority: Critical
Fix For: 2.6
In OpenEJB we would like to be able to support arbitrary mixing of text based
properties and complex elements. This patch adds support for this by merging
all text sub nodes and attempting to read them in using java.util.Properties.
This patch contains a test case which read the following xbean-spring element:
{code:xml}
p:PizzaService id=pizzaService
cheeseEdam
!-- properties can have complex elements mixed in --
p:toppingSalami/p:topping
size 17
/p:PizzaService
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r421872 - in /geronimo/trunk: ./ assemblies/j2ee-jetty-server/ assemblies/j2ee-tomcat-server/ assemblies/zzzzj2ee-installer/ configs/javamail/ configs/rmi-naming/ etc/ modules/ modules
Thanks. BTW, the new Javamail 1.3.1 spec has been built on continuum. It should be synced up w/ people.apache.org, shortly... --kevan On Jul 14, 2006, at 5:42 PM, Jason Dillon wrote: I have not had a chance to look into this more. I'm going to ping repository@ and see what the current official locations are for m2 artifacts (release + snapshot + sync to central). --jason On Jul 14, 2006, at 12:33 PM, Kevan Miller wrote: We've been letting the GBuild builds push out the Maven 1 artifacts. I was just working on getting the javamail spec into gbuild, since this is killing the Geronimo 1.2 build. We need some process for getting Maven 2 artifacts deployed. Jason, didn't you have some ideas on how to get that done? Tuscany would like our fixed Commonj spec to be published to a Maven 2 repo... --kevan On Jul 14, 2006, at 2:14 PM, Jason Dillon wrote: On Jul 14, 2006, at 11:08 AM, Rick McGuire wrote: Jason Dillon wrote: Where are the Javamail-1.3 1.2-SNAPSHOT artifacts deployed? I'm not sure they are yet. This is the level built if you build the specs freshly. What's the process of getting the snapshots published? Dunno... I need to know that too soon to start getting genesis and g 1.2-SNAPSHOTS published w/m2. I'm still kinda confused as to which are the official Apache m1 + m2 repositories. --jason
[jira] Updated: (XBEAN-24) [RTC] Support mixed nested properties and complex elements
[ http://issues.apache.org/jira/browse/XBEAN-24?page=all ]
Dain Sundstrom updated XBEAN-24:
Attachment: mixed-content.patch
[RTC] Support mixed nested properties and complex elements
--
Key: XBEAN-24
URL: http://issues.apache.org/jira/browse/XBEAN-24
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Dain Sundstrom
Assigned To: Dain Sundstrom
Priority: Critical
Fix For: 2.6
Attachments: mixed-content.patch
In OpenEJB we would like to be able to support arbitrary mixing of text based
properties and complex elements. This patch adds support for this by merging
all text sub nodes and attempting to read them in using java.util.Properties.
This patch contains a test case which read the following xbean-spring
element:
{code:xml}
p:PizzaService id=pizzaService
cheeseEdam
!-- properties can have complex elements mixed in --
p:toppingSalami/p:topping
size 17
/p:PizzaService
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XBEAN-24) [RTC] Support mixed nested properties and complex elements
[
http://issues.apache.org/jira/browse/XBEAN-24?page=comments#action_12421232 ]
Dain Sundstrom commented on XBEAN-24:
-
This patch also runs inline properties through getValue so #refs work although
there is no test for it.
[RTC] Support mixed nested properties and complex elements
--
Key: XBEAN-24
URL: http://issues.apache.org/jira/browse/XBEAN-24
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Dain Sundstrom
Assigned To: Dain Sundstrom
Priority: Critical
Fix For: 2.6
Attachments: mixed-content.patch
In OpenEJB we would like to be able to support arbitrary mixing of text based
properties and complex elements. This patch adds support for this by merging
all text sub nodes and attempting to read them in using java.util.Properties.
This patch contains a test case which read the following xbean-spring
element:
{code:xml}
p:PizzaService id=pizzaService
cheeseEdam
!-- properties can have complex elements mixed in --
p:toppingSalami/p:topping
size 17
/p:PizzaService
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r421872 - in /geronimo/trunk: ./ assemblies/j2ee-jetty-server/ assemblies/j2ee-tomcat-server/ assemblies/zzzzj2ee-installer/ configs/javamail/ configs/rmi-naming/ etc/ modules/ modules
What URL on people.* ? --jason On Jul 14, 2006, at 2:54 PM, Kevan Miller wrote: Thanks. BTW, the new Javamail 1.3.1 spec has been built on continuum. It should be synced up w/ people.apache.org, shortly... --kevan On Jul 14, 2006, at 5:42 PM, Jason Dillon wrote: I have not had a chance to look into this more. I'm going to ping repository@ and see what the current official locations are for m2 artifacts (release + snapshot + sync to central). --jason On Jul 14, 2006, at 12:33 PM, Kevan Miller wrote: We've been letting the GBuild builds push out the Maven 1 artifacts. I was just working on getting the javamail spec into gbuild, since this is killing the Geronimo 1.2 build. We need some process for getting Maven 2 artifacts deployed. Jason, didn't you have some ideas on how to get that done? Tuscany would like our fixed Commonj spec to be published to a Maven 2 repo... --kevan On Jul 14, 2006, at 2:14 PM, Jason Dillon wrote: On Jul 14, 2006, at 11:08 AM, Rick McGuire wrote: Jason Dillon wrote: Where are the Javamail-1.3 1.2-SNAPSHOT artifacts deployed? I'm not sure they are yet. This is the level built if you build the specs freshly. What's the process of getting the snapshots published? Dunno... I need to know that too soon to start getting genesis and g 1.2-SNAPSHOTS published w/m2. I'm still kinda confused as to which are the official Apache m1 + m2 repositories. --jason
Re: svn commit: r421872 - in /geronimo/trunk: ./ assemblies/j2ee-jetty-server/ assemblies/j2ee-tomcat-server/ assemblies/zzzzj2ee-installer/ configs/javamail/ configs/rmi-naming/ etc/ modules/ modules
On Jul 14, 2006, at 6:02 PM, Jason Dillon wrote: What URL on people.* ? The M1 SNAPSHOT repo -- http://people.apache.org/repository/ org.apache.geronimo.specs/jars/ It's not there yet. I'm not sure how frequent the rsync runs... --kevan --jason On Jul 14, 2006, at 2:54 PM, Kevan Miller wrote: Thanks. BTW, the new Javamail 1.3.1 spec has been built on continuum. It should be synced up w/ people.apache.org, shortly... --kevan On Jul 14, 2006, at 5:42 PM, Jason Dillon wrote: I have not had a chance to look into this more. I'm going to ping repository@ and see what the current official locations are for m2 artifacts (release + snapshot + sync to central). --jason On Jul 14, 2006, at 12:33 PM, Kevan Miller wrote: We've been letting the GBuild builds push out the Maven 1 artifacts. I was just working on getting the javamail spec into gbuild, since this is killing the Geronimo 1.2 build. We need some process for getting Maven 2 artifacts deployed. Jason, didn't you have some ideas on how to get that done? Tuscany would like our fixed Commonj spec to be published to a Maven 2 repo... --kevan On Jul 14, 2006, at 2:14 PM, Jason Dillon wrote: On Jul 14, 2006, at 11:08 AM, Rick McGuire wrote: Jason Dillon wrote: Where are the Javamail-1.3 1.2-SNAPSHOT artifacts deployed? I'm not sure they are yet. This is the level built if you build the specs freshly. What's the process of getting the snapshots published? Dunno... I need to know that too soon to start getting genesis and g 1.2-SNAPSHOTS published w/m2. I'm still kinda confused as to which are the official Apache m1 + m2 repositories. --jason
Re: Need help on classloading related problem(What is shared/lib in Apache Geronimo)
Hi Sunil, In Geronimo 1.1 you can add a jar to a shared library in Geronimo by doing the following: - Add your jars into this location: geronimo-install-root/var/shared/lib - Add the following dependency into your geronimo deployment plan: environment dependencies dependency groupIdgeronimo/groupId artifactIdsharedlib/artifactId /dependency /dependencies /environment The sharedlib support is new in Geronimo 1.1. HTH, Joe sunil patil wrote: Hi, I am trying to install Pluto 1.1 portal server into Geronimo. Till now i am able to get About and Admin portlets working. Both these portlets are part of pluto.war. Now i am facing one classloader related problem when i try to install HelloWorld Portlet in HelloWorld.war (Separate war). *Basic Problem* - I have A.war and B.war they depend on Class1 which is part of 1.jar. What i want is A.war should create object of Class1 and that object should be accessible to class in B.war so where should i put 1.jar and how should i configure both A.war and B.war so that they will be able to look at this class. *Detailed Description -* Thing is Pluto portlet has PortalDriverServlet which is controller servlet and is shipped with Pluto.war. When it gets request for HelloWorldportlet it wraps that request in object of RenderRequestImpl.java which is in pluto-container-1.1.0-dev.jar and sets is as request parameter and passes control to HelloWorldPortlet. Now HelloWOrldPortlet uses PlutoServlet.java class for handling request and this is again part of pluto-container-1.1.0-dev.jar. When PlutoServlet tries to get object of RenderRequestImpl.java from request it throws ClassCastException because both of them have different class loader. Till now i tried to 1) Create pluto in repository folder containing pluto-container-1.1.0-dev.jar and add dependencies from both pluto.war and HelloWorldPortlet.war on pluto repository. But in that case i get ClasscastException. 2) I tried copying all jars in Geronimo_Base/lib and removed dependencies but that does not work either 3) I tried copying all jars in Geronimo_Base/repository/geronimo/jars and that does not work. Can you please let me know what is equivalent of shared/lib in Geronimo. Place where i could copy jars used by more than one application Thank You Sunil
[jira] Created: (XBEAN-25) [RTC] Support for #null short hand for a null value
[RTC] Support for #null short hand for a null value --- Key: XBEAN-25 URL: http://issues.apache.org/jira/browse/XBEAN-25 Project: XBean Issue Type: Improvement Components: spring Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Priority: Critical Fix For: 2.6 Attachments: #null.patch We need a way to specify an explicit null value via an attribute. Constructors are selected using the names of the arguments present, so we need to specify the null ones. There is currently no way to do this in an xml attribute. This code allows you to put #null in any attribute and we create a property with null for the value. This patch contains a test case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-25) [RTC] Support for #null short hand for a null value
[ http://issues.apache.org/jira/browse/XBEAN-25?page=all ] Dain Sundstrom updated XBEAN-25: Attachment: #null.patch [RTC] Support for #null short hand for a null value --- Key: XBEAN-25 URL: http://issues.apache.org/jira/browse/XBEAN-25 Project: XBean Issue Type: Improvement Components: spring Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Priority: Critical Fix For: 2.6 Attachments: #null.patch We need a way to specify an explicit null value via an attribute. Constructors are selected using the names of the arguments present, so we need to specify the null ones. There is currently no way to do this in an xml attribute. This code allows you to put #null in any attribute and we create a property with null for the value. This patch contains a test case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XBEAN-25) [RTC] Support for #null short hand for a null value
[ http://issues.apache.org/jira/browse/XBEAN-25?page=comments#action_12421238 ] Dain Sundstrom commented on XBEAN-25: - Note this patch contains 4 new files which will need to be svn added. [RTC] Support for #null short hand for a null value --- Key: XBEAN-25 URL: http://issues.apache.org/jira/browse/XBEAN-25 Project: XBean Issue Type: Improvement Components: spring Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Priority: Critical Fix For: 2.6 Attachments: #null.patch We need a way to specify an explicit null value via an attribute. Constructors are selected using the names of the arguments present, so we need to specify the null ones. There is currently no way to do this in an xml attribute. This code allows you to put #null in any attribute and we create a property with null for the value. This patch contains a test case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XBEAN-24) [RTC] Support mixed nested properties and complex elements
[
http://issues.apache.org/jira/browse/XBEAN-24?page=comments#action_12421241 ]
Jason Dillon commented on XBEAN-24:
---
I'm a tad confused... this is considered a property:
{noformat}
size 17
{noformat}
I can see:
{noformat}
size: 17
{noformat}
or
{noformat}
size= 17
{noformat}
But I don't understand why it would take any text element that has a space and
turn that into properties.
Am I missing something?
[RTC] Support mixed nested properties and complex elements
--
Key: XBEAN-24
URL: http://issues.apache.org/jira/browse/XBEAN-24
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Dain Sundstrom
Assigned To: Dain Sundstrom
Priority: Critical
Fix For: 2.6
Attachments: mixed-content.patch
In OpenEJB we would like to be able to support arbitrary mixing of text based
properties and complex elements. This patch adds support for this by merging
all text sub nodes and attempting to read them in using java.util.Properties.
This patch contains a test case which read the following xbean-spring
element:
{code:xml}
p:PizzaService id=pizzaService
cheeseEdam
!-- properties can have complex elements mixed in --
p:toppingSalami/p:topping
size 17
/p:PizzaService
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r421872 - in /geronimo/trunk: ./ assemblies/j2ee-jetty-server/ assemblies/j2ee-tomcat-server/ assemblies/zzzzj2ee-installer/ configs/javamail/ configs/rmi-naming/ etc/ modules/ modules
I will apply this to m2migration once we have the latest specs
published to the m2 repo.
Else we will have to bootstrap the specs... :-(
--jason
On Jul 14, 2006, at 4:26 AM, [EMAIL PROTECTED] wrote:
Author: rickmcguire
Date: Fri Jul 14 04:26:41 2006
New Revision: 421872
URL: http://svn.apache.org/viewvc?rev=421872view=rev
Log:
GERONIMO-2147 Remove javamail-transport from Geronimo build and
replace with javamail-provider dependency.
Removed:
geronimo/trunk/modules/javamail-transport/
Modified:
geronimo/trunk/assemblies/j2ee-jetty-server/project.xml
geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml
geronimo/trunk/assemblies/j2ee-installer/project.xml
geronimo/trunk/configs/javamail/project.xml
geronimo/trunk/configs/rmi-naming/project.xml
geronimo/trunk/etc/project.properties
geronimo/trunk/modules/activation/project.xml
geronimo/trunk/modules/axis/project.xml
geronimo/trunk/modules/mail/pom.xml
geronimo/trunk/modules/mail/project.xml
geronimo/trunk/modules/pom.xml
geronimo/trunk/modules/upgrade/src/test-data/appclient_dep_1.xml
geronimo/trunk/modules/upgrade/src/test-data/
appclient_dep_1_result.xml
geronimo/trunk/pom.xml
Modified: geronimo/trunk/assemblies/j2ee-jetty-server/project.xml
URL: http://svn.apache.org/viewvc/geronimo/trunk/assemblies/j2ee-
jetty-server/project.xml?rev=421872r1=421871r2=421872view=diff
==
--- geronimo/trunk/assemblies/j2ee-jetty-server/project.xml (original)
+++ geronimo/trunk/assemblies/j2ee-jetty-server/project.xml Fri Jul
14 04:26:41 2006
@@ -25,7 +25,7 @@
descriptionAn assembly of Geronimo into a J2EE Server using
Jetty as the web container/description
dependencies
-!-- plugin we use --
+!-- plugin we use --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-assembly-plugin/artifactId
@@ -292,7 +292,7 @@
geronimo.assembleinstall/geronimo.assemble
/properties
/dependency
-!-- unpack --
+!-- unpack --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-scripts/artifactId
@@ -359,7 +359,7 @@
geronimo.assemblelibrary/geronimo.assemble
/properties
/dependency
-
+
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-kernel/artifactId
@@ -368,7 +368,7 @@
geronimo.assemblelibrary/geronimo.assemble
/properties
/dependency
-
+
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-system/artifactId
@@ -639,7 +639,7 @@
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-javamail_1.3.1_spec/artifactId
-version${geronimo_spec_javamail_version}/version
+version${geronimo_spec_javamail_13_version}/version
/dependency
dependency
groupIdorg.apache.geronimo.specs/groupId
@@ -701,14 +701,14 @@
dependency
groupIdantlr/groupId
artifactIdantlr/artifactId
-version${antlr_version}/version
+version${antlr_version}/version
/dependency
dependency
!--what is using this? --
groupIdasm/groupId
artifactIdasm/artifactId
-version${asm_version}/version
+version${asm_version}/version
/dependency
dependency
@@ -1018,7 +1018,7 @@
/dependency
!-- Specification dependencies to preload into the
repository --
-
+
!-- Geronimo modules to preload into the repository --
dependency
groupIdgeronimo/groupId
Modified: geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml
URL: http://svn.apache.org/viewvc/geronimo/trunk/assemblies/j2ee-
tomcat-server/project.xml?rev=421872r1=421871r2=421872view=diff
==
--- geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml
(original)
+++ geronimo/trunk/assemblies/j2ee-tomcat-server/project.xml Fri
Jul 14 04:26:41 2006
@@ -25,7 +25,7 @@
descriptionAn assembly of Geronimo into a J2EE Server using
Tomcat for the web container/description
dependencies
-!-- plugin we use --
+!-- plugin we use --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-assembly-plugin/artifactId
@@ -292,7 +292,7 @@
geronimo.assembleinstall/geronimo.assemble
/properties
/dependency
-!-- unpack --
+!-- unpack --
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-scripts/artifactId
@@ -359,7 +359,7 @@
geronimo.assemblelibrary/geronimo.assemble
/properties
[jira] Commented: (XBEAN-24) [RTC] Support mixed nested properties and complex elements
[
http://issues.apache.org/jira/browse/XBEAN-24?page=comments#action_12421251 ]
Jeff Genender commented on XBEAN-24:
+1...this patch looks good to me.
[RTC] Support mixed nested properties and complex elements
--
Key: XBEAN-24
URL: http://issues.apache.org/jira/browse/XBEAN-24
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Dain Sundstrom
Assigned To: Dain Sundstrom
Priority: Critical
Fix For: 2.6
Attachments: mixed-content.patch
In OpenEJB we would like to be able to support arbitrary mixing of text based
properties and complex elements. This patch adds support for this by merging
all text sub nodes and attempting to read them in using java.util.Properties.
This patch contains a test case which read the following xbean-spring
element:
{code:xml}
p:PizzaService id=pizzaService
cheeseEdam
!-- properties can have complex elements mixed in --
p:toppingSalami/p:topping
size 17
/p:PizzaService
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XBEAN-24) [RTC] Support mixed nested properties and complex elements
[
http://issues.apache.org/jira/browse/XBEAN-24?page=comments#action_12421252 ]
Dain Sundstrom commented on XBEAN-24:
-
Jason this code didn't add the nested properties files support, but only adds
support for mixed complex elements in the text.
Anyway, the code simply passes the text to properties.load(in) which supports
'=' ':' and white space to split names from values.
[RTC] Support mixed nested properties and complex elements
--
Key: XBEAN-24
URL: http://issues.apache.org/jira/browse/XBEAN-24
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Dain Sundstrom
Assigned To: Dain Sundstrom
Priority: Critical
Fix For: 2.6
Attachments: mixed-content.patch
In OpenEJB we would like to be able to support arbitrary mixing of text based
properties and complex elements. This patch adds support for this by merging
all text sub nodes and attempting to read them in using java.util.Properties.
This patch contains a test case which read the following xbean-spring
element:
{code:xml}
p:PizzaService id=pizzaService
cheeseEdam
!-- properties can have complex elements mixed in --
p:toppingSalami/p:topping
size 17
/p:PizzaService
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XBEAN-24) [RTC] Support mixed nested properties and complex elements
[
http://issues.apache.org/jira/browse/XBEAN-24?page=comments#action_12421253 ]
Jason Dillon commented on XBEAN-24:
---
Mmkay. I did not realize that Properties.load() supported whitespace as a
delim.
It looks good to me... forgive my ignorance :-)
[RTC] Support mixed nested properties and complex elements
--
Key: XBEAN-24
URL: http://issues.apache.org/jira/browse/XBEAN-24
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Dain Sundstrom
Assigned To: Dain Sundstrom
Priority: Critical
Fix For: 2.6
Attachments: mixed-content.patch
In OpenEJB we would like to be able to support arbitrary mixing of text based
properties and complex elements. This patch adds support for this by merging
all text sub nodes and attempting to read them in using java.util.Properties.
This patch contains a test case which read the following xbean-spring
element:
{code:xml}
p:PizzaService id=pizzaService
cheeseEdam
!-- properties can have complex elements mixed in --
p:toppingSalami/p:topping
size 17
/p:PizzaService
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Problem using geronimo datasource
Hi, I have been trying for 4 weeks to created a server wide datasource connecting to a mysql database. I have then updated the web.xml and geronimo-web.xml. however, when i access my web app (servlet) i'm receiving a: javax.naming.NameNotFoundException: enc/jdbc/Datasource at org.apache.geronimo.naming.enc.AbstractReadOnlyContext.lookup(AbstractReadOnlyContext.java:81) I have read Aaron Mulder docs but things are not any clearer. I guess this has been must have been discussed before on the list so if anyone has any pointers I'll be very grateful. I'm using geronimo 1.1 on Windows JDK 1.4.2 Rgds Peter _ Windows Live Messenger has arrived. Click here to download it for free! http://imagine-msn.com/messenger/launch80/?locale=en-gb
Re: [m2 build] Update about custom assembly usage
Would it not be simpler to use the patched version of m-a-p and just rename it to geronimo-assembly2-plugin and add it to our code base? This plugin is more elegant than the ant solution. we can remove this code as soon as maven-assembly-plugin is updated. Are there any problems with using code like this? BTW, I saw your comments about remote-deploy-* configs. These are the pending patches at - http://issues.apache.org/jira/browse/GERONIMO-2067#action_12415761 I will be offline for next 2 weeks due to preplanned summer engagements. Cheers Anita --- Jason Dillon [EMAIL PROTECTED] wrote: It looks like the Maven 2 peeps are not going to be able to take in our patches to apply to the assembly plugin, which provides mappers and some includes/excludes to unpack and a permission related fix to files/file element processing. I believe that those changes will eventually make it in, but for now to get around the need Prasad and I talked about using the dependency plugin and the antrun plugin to perform the needed flattening of the schema files for the /schema/* in the assembly. I've implemented this already for the geronimo-jetty-j2ee assembly in the svkmerge/m2migration branch. It appears to function as expected. I've disabled the remaining assemblies which have not yet been converted. Once they have been converted they will be re-enabled. Note, we are still using car:installConfigs... but we no longer need to have MASSEMBLY-45 or MASSEMBLY-127 applied to a custom 2.2- SNAPSHOT version of the maven-assembly-plugin to build out assemblies. The full conversation is here if anyone is interested: http://uwyn.com/drone/log/bevinbot/geronimo/20060714 Starts with '19:53 jdillon any thoughts on using dependency + antrun to setup the right bits and then use the 2.1 assembly plugin?' --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [m2 build] Update about custom assembly usage
On Jul 14, 2006, at 4:30 PM, anita kulshreshtha wrote: Would it not be simpler to use the patched version of m-a-p and just rename it to geronimo-assembly2-plugin and add it to our code base? I do not believe so. The use of the dependency + antrun plugins are relatively limited. Both solutions are hacks IMO... and IMO the lesser of the two is to use the released version of the assembly plugin + dependency and antrun. We are also not certain that the patches to the assembly plugin will be committed... and if they will be we are not sure when. I'd be happy to change this up once the new assembly plugin with support can do this for us. Short of that I believe the solution applied to the geronimo-jetty-j2ee assembly is the most optimal given the situation. This plugin is more elegant than the ant solution. we can remove this code as soon as maven-assembly-plugin is updated. Are there any problems with using code like this? There are no other problems that I am aware of. BTW, I saw your comments about remote-deploy-* configs. These are the pending patches at - http://issues.apache.org/jira/browse/GERONIMO-2067#action_12415761 I believe that was Prasad, not I who commented on this... but we will take a look. Thanks :-) I will be offline for next 2 weeks due to preplanned summer engagements. Enjoy. --jason
[jira] Created: (XBEAN-26) [RTC] Nested properties not evaluated for named constructor args
[RTC] Nested properties not evaluated for named constructor args
Key: XBEAN-26
URL: http://issues.apache.org/jira/browse/XBEAN-26
Project: XBean
Issue Type: Bug
Components: spring
Reporter: Dain Sundstrom
Assigned To: Dain Sundstrom
Fix For: 2.6
Nested property elements are not evaluated when they are constructor arguments.
For example the following three declarations should be equivalent:
{code}
s:soup id=soupService type=French Onion/
s:soup id=nestedBean
s:type
bean class=java.lang.String
constructor-arg index=0 value=French Onion/
/bean
/s:type
/s:soup
s:soup id=nestedValue
s:type
valueFrench Onion/value
/s:type
/s:soup
{code}
The patch attempts to find a setter for the property and if not located assumes
it is type Object instead of just aborting the evaluation. This means that
constructor args without a matching getter or setter can't support our custom
map element code because we don't knot the type of the constructor argument at
this point in the code. Fixing that will take a much bigger restructure of the
code.
There are test cases included with the patch. Note there is one new file
included with the patch that must be svn added.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-26) [RTC] Nested properties not evaluated for named constructor args
[ http://issues.apache.org/jira/browse/XBEAN-26?page=all ]
Dain Sundstrom updated XBEAN-26:
Attachment: named-constructor-arg-fixes.patch
[RTC] Nested properties not evaluated for named constructor args
Key: XBEAN-26
URL: http://issues.apache.org/jira/browse/XBEAN-26
Project: XBean
Issue Type: Bug
Components: spring
Reporter: Dain Sundstrom
Assigned To: Dain Sundstrom
Fix For: 2.6
Attachments: named-constructor-arg-fixes.patch
Nested property elements are not evaluated when they are constructor
arguments. For example the following three declarations should be equivalent:
{code}
s:soup id=soupService type=French Onion/
s:soup id=nestedBean
s:type
bean class=java.lang.String
constructor-arg index=0 value=French Onion/
/bean
/s:type
/s:soup
s:soup id=nestedValue
s:type
valueFrench Onion/value
/s:type
/s:soup
{code}
The patch attempts to find a setter for the property and if not located
assumes it is type Object instead of just aborting the evaluation. This
means that constructor args without a matching getter or setter can't support
our custom map element code because we don't knot the type of the constructor
argument at this point in the code. Fixing that will take a much bigger
restructure of the code.
There are test cases included with the patch. Note there is one new file
included with the patch that must be svn added.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[xbean] duplicated tests in xbean-spring v1 and v2
Recently I have been working on adding new features and bug fixes to the xbean-spring code. This code is a lot harder to work with since the test have been coppied into the v1 and v2 modules. It actually make it very easy to make a change in v1 and not apply the same change to v2 since the test suites are split. I suggest we: o move the test to the xbean-common module o exclude all the tests from running in xbean-common o publish a test jar from xbean-common o add the tests to v1 and v2 as a dependency What do you think? -dain
Re: Cluster API proposal?
Dain Sundstrom wrote: I think we are starting to agree. agreed :-) I think that a Cluster interface with the stateless methods as proposed by filip would be good, plus a SessionManager interface with the stateful stuff. Actually, I don't like SessionManager as a name... maybe StateManager? If the same bean implements both APIs, great! But I see no need for a common root. I am still keen on a context ID, but I'll advocate that in a separate email. cheers
Re: svn commit: r421991 - /geronimo/sandbox/svkmerge/m2migration/modules/system/src/java/org/apache/geronimo/system/repository/AbstractRepository.java
That is my code and it should be removed. I only added it for
debugging when working on configId branch.
-dain
On Jul 14, 2006, at 12:18 PM, [EMAIL PROTECTED] wrote:
Author: jdillon
Date: Fri Jul 14 12:18:04 2006
New Revision: 421991
URL: http://svn.apache.org/viewvc?rev=421991view=rev
Log:
Comment about crummy usage of System.out
Modified:
geronimo/sandbox/svkmerge/m2migration/modules/system/src/java/
org/apache/geronimo/system/repository/AbstractRepository.java
Modified: geronimo/sandbox/svkmerge/m2migration/modules/system/src/
java/org/apache/geronimo/system/repository/AbstractRepository.java
URL: http://svn.apache.org/viewvc/geronimo/sandbox/svkmerge/
m2migration/modules/system/src/java/org/apache/geronimo/system/
repository/AbstractRepository.java?
rev=421991r1=421990r2=421991view=diff
==
--- geronimo/sandbox/svkmerge/m2migration/modules/system/src/java/
org/apache/geronimo/system/repository/AbstractRepository.java
(original)
+++ geronimo/sandbox/svkmerge/m2migration/modules/system/src/java/
org/apache/geronimo/system/repository/AbstractRepository.java Fri
Jul 14 12:18:04 2006
@@ -217,7 +217,11 @@
ArtifactTypeHandler typeHandler = (ArtifactTypeHandler)
typeHandlers.get(destination.getType());
if (typeHandler == null) typeHandler = DEFAULT_TYPE_HANDLER;
typeHandler.install(source, size, destination, monitor,
location);
-
+
+//
+// FIXME: This should not be here... if you need this
intel then add logging
+//
+
if (destination.getType().equalsIgnoreCase(car)) {
System.out.println
();
System.out.println(# Installed configuration);
[jira] Commented: (XBEAN-3) XBean generator fails when parsing JDK 5 source files with annotations
[ http://issues.apache.org/jira/browse/XBEAN-3?page=comments#action_12421262 ] Dain Sundstrom commented on XBEAN-3: QDox 1.6 is working for in OpenEJB 3 me but there are still some things it doesn't handle correctly like the operator. XBean generator fails when parsing JDK 5 source files with annotations -- Key: XBEAN-3 URL: http://issues.apache.org/jira/browse/XBEAN-3 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.3 Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Upgrading JIRA later today
On Fri, Jul 14, 2006 at 10:30:53AM -0700, Jason Dillon wrote: How did this go? Looks like issues is running 3.6.3-DEV-ASF-#156... does this fix the wiki bits? Yes. I've just reenabled wiki syntax for GERONIMO and GBUILD. I don't see the tools plugin or the graph plugin though :-( Are those going to make it in? Not immediately. In the past the toolkit/charting plugins have introduced performance and memory problems, and I'd like to see JIRA running for a few days on vanilla 3.6.x before introducing new variables. --Jeff --jason On Jul 13, 2006, at 8:06 PM, Jeff Turner wrote: Hi, At about 7am UTC: http://www.timeanddate.com/worldclock/fixedtime.html? month=7day=14year=2006hour=17min=0sec=0p1=240 I'd like to upgrade JIRA to 3.6.x This will fix an XSS hole in wiki rendering (currently disabled), fix the bug that led to HTTPS being disabled, and allow us to import the Torque CSV data. --Jeff
Re: [m2 build] Update about custom assembly usage
I tried the latest changes on Windows and it builds the assembly fine. I even ran the jetty binary successfully. Jason, I also tried commenting out a few builders from the dependencies list and it still worked fine. So I guess we can prune the deps list to remove the redudant ones. A full extract and bootstrap on Linux is running. Cheers Prasad On 7/14/06, Jason Dillon [EMAIL PROTECTED] wrote: It looks like the Maven 2 peeps are not going to be able to take in our patches to apply to the assembly plugin, which provides mappers and some includes/excludes to unpack and a permission related fix to files/file element processing. I believe that those changes will eventually make it in, but for now to get around the need Prasad and I talked about using the dependency plugin and the antrun plugin to perform the needed flattening of the schema files for the /schema/* in the assembly. I've implemented this already for the geronimo-jetty-j2ee assembly in the svkmerge/m2migration branch. It appears to function as expected. I've disabled the remaining assemblies which have not yet been converted. Once they have been converted they will be re-enabled. Note, we are still using car:installConfigs... but we no longer need to have MASSEMBLY-45 or MASSEMBLY-127 applied to a custom 2.2- SNAPSHOT version of the maven-assembly-plugin to build out assemblies. The full conversation is here if anyone is interested: http://uwyn.com/drone/log/bevinbot/geronimo/20060714 Starts with '19:53 jdillon any thoughts on using dependency + antrun to setup the right bits and then use the 2.1 assembly plugin?' --jason
Re: [xbean] duplicated tests in xbean-spring v1 and v2
Dain Sundstrom wrote: Recently I have been working on adding new features and bug fixes to the xbean-spring code. This code is a lot harder to work with since the test have been coppied into the v1 and v2 modules. It actually make it very easy to make a change in v1 and not apply the same change to v2 since the test suites are split. I suggest we: o move the test to the xbean-common module o exclude all the tests from running in xbean-common o publish a test jar from xbean-common o add the tests to v1 and v2 as a dependency What do you think? -dain Makes sense to me. Regards, Alan
Re: svn commit: r421991 - /geronimo/sandbox/svkmerge/m2migration/modules/system/src/java/org/apache/geronimo/system/repository/AbstractRepository.java
IMO, I think that the m2migration branch should focus solely on m2
migration and leave the cruft cleaning for another effort.
Regards,
Alan
Dain Sundstrom wrote:
That is my code and it should be removed. I only added it for
debugging when working on configId branch.
-dain
On Jul 14, 2006, at 12:18 PM, [EMAIL PROTECTED] wrote:
Author: jdillon
Date: Fri Jul 14 12:18:04 2006
New Revision: 421991
URL: http://svn.apache.org/viewvc?rev=421991view=rev
Log:
Comment about crummy usage of System.out
Modified:
geronimo/sandbox/svkmerge/m2migration/modules/system/src/java/org/apache/geronimo/system/repository/AbstractRepository.java
Modified:
geronimo/sandbox/svkmerge/m2migration/modules/system/src/java/org/apache/geronimo/system/repository/AbstractRepository.java
URL:
http://svn.apache.org/viewvc/geronimo/sandbox/svkmerge/m2migration/modules/system/src/java/org/apache/geronimo/system/repository/AbstractRepository.java?rev=421991r1=421990r2=421991view=diff
==
---
geronimo/sandbox/svkmerge/m2migration/modules/system/src/java/org/apache/geronimo/system/repository/AbstractRepository.java
(original)
+++
geronimo/sandbox/svkmerge/m2migration/modules/system/src/java/org/apache/geronimo/system/repository/AbstractRepository.java
Fri Jul 14 12:18:04 2006
@@ -217,7 +217,11 @@
ArtifactTypeHandler typeHandler = (ArtifactTypeHandler)
typeHandlers.get(destination.getType());
if (typeHandler == null) typeHandler = DEFAULT_TYPE_HANDLER;
typeHandler.install(source, size, destination, monitor,
location);
-
+
+//
+// FIXME: This should not be here... if you need this intel
then add logging
+//
+
if (destination.getType().equalsIgnoreCase(car)) {
System.out.println();
System.out.println(# Installed configuration);
Re: An interesting discovery about CSSBean.
+1 but, I would classify it as a bug fix not a change. Regards, Alan Dain Sundstrom wrote: +1 to make the change (pending tck verification) -dain On Jul 14, 2006, at 5:18 AM, Rick McGuire wrote: I've been taking some hard looks at all of the places where Geronimo creates/configures ORB instances as part of an effort to enable Geronimo for using the Yoko ORB. As a result, I've made an interesting discovery about how CSSBean is working that might warrant a 1.1.1 bug fix. The first part of the discovery was an issue I raised a couple days ago about CSSBean creating 2 ORB instances where 1 would be sufficient. That change simplified the configuration, and also eliminated one of the two threads that CSSBean is creating. The new discovery is that BOTH of the threads that CSSBean creates are unncessary. The two threads that CSSBean creates merely make a call to orb.run(), assuming that run() somehow started ORB execution, and since it was a blocking call, it needed to work on a separate thread. A reasonable assumption, but that's not the purpose of run() at all! The ORB run() method: This operation blocks the current thread until the ORB has completed the shutdown process, initiated when some thread calls |shutdown|. It may be used by multiple threads which get all notified when the ORB shuts down. run() doesn't start anything up at all, it merely waits until the ORB is destroyed. It is not necessary to call run() to use the ORB as a client, so those two threads don't do anything but sit there and wait for the two ORB instances to be destroyed. They're not necessary for GC purposes, because the CSSBean is holding the references (and in fact, is the code that will eventually issue the destroy() call that will terminate the 2 threads). As part of the Yoko changes, I've been reworking this, but there's a pretty good resource boost to be gained, so it might be worthwhile applying at least the thread removal to the 1.1.1 base. Rick
Re: [m2 build] Update about custom assembly usage
The bootstrap on linux first failed a test in the security module. I ran the build inside the security module. It passed successfully. Then I ran bootstrap again. It failed while transferring an artifact. Now I'm running mvn from top level. This is running. Keeping my fingers crossed Prasad On 7/14/06, Prasad Kashyap [EMAIL PROTECTED] wrote: I tried the latest changes on Windows and it builds the assembly fine. I even ran the jetty binary successfully. Jason, I also tried commenting out a few builders from the dependencies list and it still worked fine. So I guess we can prune the deps list to remove the redudant ones. A full extract and bootstrap on Linux is running. Cheers Prasad On 7/14/06, Jason Dillon [EMAIL PROTECTED] wrote: It looks like the Maven 2 peeps are not going to be able to take in our patches to apply to the assembly plugin, which provides mappers and some includes/excludes to unpack and a permission related fix to files/file element processing. I believe that those changes will eventually make it in, but for now to get around the need Prasad and I talked about using the dependency plugin and the antrun plugin to perform the needed flattening of the schema files for the /schema/* in the assembly. I've implemented this already for the geronimo-jetty-j2ee assembly in the svkmerge/m2migration branch. It appears to function as expected. I've disabled the remaining assemblies which have not yet been converted. Once they have been converted they will be re-enabled. Note, we are still using car:installConfigs... but we no longer need to have MASSEMBLY-45 or MASSEMBLY-127 applied to a custom 2.2- SNAPSHOT version of the maven-assembly-plugin to build out assemblies. The full conversation is here if anyone is interested: http://uwyn.com/drone/log/bevinbot/geronimo/20060714 Starts with '19:53 jdillon any thoughts on using dependency + antrun to setup the right bits and then use the 2.1 assembly plugin?' --jason
Re: [m2 build] Update about custom assembly usage
The timer tests failed. Jason, I thought you pulled them out late last night after our discussion. Cheers Prasad On 7/14/06, Prasad Kashyap [EMAIL PROTECTED] wrote: The bootstrap on linux first failed a test in the security module. I ran the build inside the security module. It passed successfully. Then I ran bootstrap again. It failed while transferring an artifact. Now I'm running mvn from top level. This is running. Keeping my fingers crossed Prasad On 7/14/06, Prasad Kashyap [EMAIL PROTECTED] wrote: I tried the latest changes on Windows and it builds the assembly fine. I even ran the jetty binary successfully. Jason, I also tried commenting out a few builders from the dependencies list and it still worked fine. So I guess we can prune the deps list to remove the redudant ones. A full extract and bootstrap on Linux is running. Cheers Prasad On 7/14/06, Jason Dillon [EMAIL PROTECTED] wrote: It looks like the Maven 2 peeps are not going to be able to take in our patches to apply to the assembly plugin, which provides mappers and some includes/excludes to unpack and a permission related fix to files/file element processing. I believe that those changes will eventually make it in, but for now to get around the need Prasad and I talked about using the dependency plugin and the antrun plugin to perform the needed flattening of the schema files for the /schema/* in the assembly. I've implemented this already for the geronimo-jetty-j2ee assembly in the svkmerge/m2migration branch. It appears to function as expected. I've disabled the remaining assemblies which have not yet been converted. Once they have been converted they will be re-enabled. Note, we are still using car:installConfigs... but we no longer need to have MASSEMBLY-45 or MASSEMBLY-127 applied to a custom 2.2- SNAPSHOT version of the maven-assembly-plugin to build out assemblies. The full conversation is here if anyone is interested: http://uwyn.com/drone/log/bevinbot/geronimo/20060714 Starts with '19:53 jdillon any thoughts on using dependency + antrun to setup the right bits and then use the 2.1 assembly plugin?' --jason
Re: An interesting discovery about CSSBean.
+1 ...good detective work Rick. Rick McGuire wrote: I've been taking some hard looks at all of the places where Geronimo creates/configures ORB instances as part of an effort to enable Geronimo for using the Yoko ORB. As a result, I've made an interesting discovery about how CSSBean is working that might warrant a 1.1.1 bug fix. The first part of the discovery was an issue I raised a couple days ago about CSSBean creating 2 ORB instances where 1 would be sufficient. That change simplified the configuration, and also eliminated one of the two threads that CSSBean is creating. The new discovery is that BOTH of the threads that CSSBean creates are unncessary. The two threads that CSSBean creates merely make a call to orb.run(), assuming that run() somehow started ORB execution, and since it was a blocking call, it needed to work on a separate thread. A reasonable assumption, but that's not the purpose of run() at all! The ORB run() method: This operation blocks the current thread until the ORB has completed the shutdown process, initiated when some thread calls |shutdown|. It may be used by multiple threads which get all notified when the ORB shuts down. run() doesn't start anything up at all, it merely waits until the ORB is destroyed. It is not necessary to call run() to use the ORB as a client, so those two threads don't do anything but sit there and wait for the two ORB instances to be destroyed. They're not necessary for GC purposes, because the CSSBean is holding the references (and in fact, is the code that will eventually issue the destroy() call that will terminate the 2 threads). As part of the Yoko changes, I've been reworking this, but there's a pretty good resource boost to be gained, so it might be worthwhile applying at least the thread removal to the 1.1.1 base. Rick
Re: geronimo-spec-corba-1.0.jar was never published to ibiblio
I'll take a look at that tomorrow Kevan. Kevan Miller wrote: It looks like we didn't release geronimo-spec-corba-1.0.jar when we released the last round of geronimo specs. The only repo in which I can find the jar is people.apache.org/repository (http://people.apache.org/repository/geronimo-spec/jars/geronimo-spec-corba-1.0.jar). Matt or Alan, is that something you can take care of? --kevan
[jira] Assigned: (GERONIMO-2189) Release geronimo-spec-corba-1.0.jar to ibiblio
[ http://issues.apache.org/jira/browse/GERONIMO-2189?page=all ] Matt Hogstrom reassigned GERONIMO-2189: --- Assignee: Matt Hogstrom Release geronimo-spec-corba-1.0.jar to ibiblio -- Key: GERONIMO-2189 URL: http://issues.apache.org/jira/browse/GERONIMO-2189 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: dependencies Affects Versions: 1.1 Reporter: Kevan Miller Assigned To: Matt Hogstrom geronimo-spec-corba-1.0.jar is not on ibiblio... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Timeframe for release 1.2
Jan, I've been travelling a bit lately and haven't gotten 1.1.1 off the ground. I think the 1.2 discussion is pretty important. I'll start a thread for 1.2 on content and let's flush out the time from that. Jan Bartel wrote: Now that 1.1 is out the door (BTW congrats everyone) ... time to start thinking of 1.2! I'm still working away in the servlet-2.5 sandbox, and I'd appreciate it if someone could tell me if there is a feeling for when 1.2 might be ready? regards Jan
[DISCUSSION] Content for 1.2
All, Its time to start defining the content of what everyone is planning on doing for 1.2. The biggest change so far that I'm aware of are the refactoring of OEJB by Dain and the Maven 2 work done by JDillon, Prasad, Anita and others. Not too much content from an end-user perspective. I think DJencks was doing some work on pluggable JAAC as well. In the spirit of kicking 1.2 off can you post to this thread the things you'd like to get into 1.2? I've heard many folks indiciate that the community would like to time box releases so they don't go on forever so to kick it off I'd think development through the end of August (that's when we'd branch) with a release toward the end of September sounds about right. Here's a strawman format for the ideas with my 2c in there. ProposerDescription HogstromImprove tomcat, Jetty and Connector instrumentation HogstromSPECjAppServer Performance improvements. Let the games begin...
[jira] Closed: (GERONIMO-2184) Geronimo/Openejb does not support all isolation levels
[ http://issues.apache.org/jira/browse/GERONIMO-2184?page=all ] Matt Hogstrom closed GERONIMO-2184. --- Resolution: Fixed This is a duplicate of 2128 Geronimo/Openejb does not support all isolation levels -- Key: GERONIMO-2184 URL: http://issues.apache.org/jira/browse/GERONIMO-2184 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Environment: All Supported Environments Reporter: Manu T George Geronimo/Openejb does not support isolation level other than Read Committed isolation level. Lacks support for other isolation levels for consistency of data. Support for isolation levels such as repeatable-read, serializable, read-committed, and read-uncommitted are required. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2194) Eclipse project names not generated consistently
Eclipse project names not generated consistently
Key: GERONIMO-2194
URL: http://issues.apache.org/jira/browse/GERONIMO-2194
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: buildsystem
Affects Versions: 1.1
Environment: Maven eclipse plugin version 1.11
Reporter: John Sisson
Assigned To: John Sisson
Priority: Trivial
Fix For: 1.1.1
h1. Problem
When running maven the maven eclipse plugin to generate eclipse projects for
Geronimo, e.g.
{{maven m:eclipse -Dmaven.eclipse.src.download=false}}
A number of configs and modules eclipse project names are not built using the
{{geronimo.maven.eclipse.xx}} properties in the
{{geronimo/etc/project.properties}} file.
(i) This problem only impacts developers working on Geronimo itself who use
eclipse with version 1.11 or later of the maven eclipse plugin.
h1. Symptom
When importing existing projects into eclipse you will see the following
projects do not have a prefix that you specified in the
{{geronimo/etc/project.properties}} file:
* axis
* axis-deployer
* client-deployer
* ge-activemq-rar
* shared-lib
* unavailable-client-deployer
* unavailable-ejb-deployer
* unavailable-webservices-deployer
h1. Cause
A number of new project.properties files have been added since GERONIMO-1856
was committed before the 1.1 release was shipped. These newly added
project.properties files did not set the {{maven.eclipse.project.name}}
property like other Geronimo projects.
h1. Solution
The newly added project.property files have been fixed so that they set the
{{maven.eclipse.project.name}} property like the other Geronimo modules/configs.
h1. Workaround
None.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Idea] adding m2 plugins to run the various non-Java ActiveMQ clients...
We've got a great maven 2 plugin for running brokers and performance test producers and consumers that will generate nice reports... http://incubator.apache.org/activemq/activemq-performance-module-users-manual.html We should be able to setup automated performance test runs on different hardware along with soak tests using this. What we urgently need is a way to automatically test out the various cross language clients we have - particularly C, C++ and C# but also the various scripting clients. We can build the plugins for C++ and C# using the m2 plugins; I wonder if we could create m2 plugins to compile then run the C++ / C# clients against a broker to create an automated integration test? Even if we just use 1 box and run the broker in another process then try run a test suite in C++ / C# it'd be great win. Anyone fancy taking a stab at it? -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (AMQ-823) Incorect handling of message size in ByteArrayOutputStream::write
Incorect handling of message size in ByteArrayOutputStream::write - Key: AMQ-823 URL: https://issues.apache.org/activemq/browse/AMQ-823 Project: ActiveMQ Issue Type: Bug Components: CMS Affects Versions: incubation Environment: RHEL 4/32bit Reporter: Radek Sedmak when you are sending message via openwire protocol, ByteArrayOutputStream::write is called in certain moment ... when message size is greater then defaul CHUNK space is reallocated and there is check for EOF offset. if( offset bodySize ) expandBody() ; but should be there if ( offset = bodySize ) expandBody(); -- 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: dependency ServiceMix SNAPSHOT on Maven2
I just downloaded and unzipped this file OK http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/apache-servicemix/3.0-incubating-SNAPSHOT/apache-servicemix-3.0-incubating-20060620.224738-1-src.zip which file did you have trouble with? You could try the tar.gz if the zip isn't working on your machine On 7/14/06, greggy [EMAIL PROTECTED] wrote: I pulled down the source from that location and i could not extract due to a password on some files - or it is simply corrupted source files? -- View this message in context: http://www.nabble.com/dependency-ServiceMix-SNAPSHOT-on-Maven2-tf1870244.html#a5319668 Sent from the ServiceMix - Dev forum at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (SM-487) network clogging when service mix runs
network clogging when service mix runs -- Key: SM-487 URL: https://issues.apache.org/activemq/browse/SM-487 Project: ServiceMix Issue Type: Bug Affects Versions: 3.0-M1, 3.0-M2, 3.0 Environment: Linux 2.6.x (Suse 10 and Gentoo), Java 1.5.0_0x Reporter: Anand K Kalyanasundaram Priority: Critical Fix For: 2.0.2 Running servicemix 3.0 overloads the network on a linux machine. This does not happen with service mix 2.0.2. This happens with service mix 3.0-M1, 3.0-M2 and 3.0-SNAPSHOT and all of them consistently caused a server configured linux machine to become unresponsive on the network. On a linux desktop, the machine was responsive, but all outgoing and incomming connections to the machine where incurring huge latencies. -- 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
packaging servicemix
Hi All, I'm a new user/developer of servicemix.. I recently built servicemix on my computer... my question is fairly straight forward (I hope)... how do I package up the files that I've built so that I can install and test them? I'm trying: mvn package which is not working on my machine... I guess a more general question is how do you all setup your machines for devloping in and extending servicemix? Thanks in advance, -Leo -- View this message in context: http://www.nabble.com/packaging-servicemix-tf1943941.html#a5329113 Sent from the ServiceMix - Dev forum at Nabble.com.
