Re: LDAP Authorization
Sounds great! I didn't see an attachment - I wonder it might be easier if you raised a JIRA and attached your zip to the JIRA issue? On 7/15/06, ngcutura [EMAIL PROTECTED] wrote: Hi all, I followed James' advice and created simple LDAPAuthorizationMap. It has no support for wildcards or composite destinations at the moment. Attached is a zip archive with 4 files: LdapAuth.zip - LDAPAuthorizationMap.java (module code) - LDAPAuthorizationMapTest.java (module test) - LDAPAuthorizationMap.properties (list of module properties) - AMQAuth.ldif (sample directory used for testing) Module works through JUnit tests. To run the tests you need to setup a directory. I used ApacheDS; export of my sample directory is in the file AMQAuth.ldif. Contents of this file is also present in LDAPAuthorizationMapTest.java. I am not familiar with Spring and I was not able to deduce how to specify module properties in AMQ XML config file. I need help with this and I would very much appreciate the following: - given the LDAPAuthorizationMap.properties file produce XML file - given the LDAPAuthorizationMap.java add code changes to accept properties from XML file above I am pretty much sure that my choice of constructor taking Map as argument is inappropraite but having no knowledge of Spring one choice was as good as another for me. Regards, NGC James.Strachan wrote: On 6/29/06, ngcutura [EMAIL PROTECTED] wrote: Thank you for reply. There is no bean class=com.acme... ... in security example but this is quite important. Thats just a way to instantiate some JavaBean using regular Spring style syntax. Is there some default class like DefaultAuthorizationMap? Yes - by all means derive from that if you want. What would this declaration be exactly for the security example you referred to? I think I can manage AuthorizationEntry by subclassing it or adding another parse() method. You could ignore the DefaultAuthorizationMap/AuthorizationEntry entirely and just walk JNDI/LDAP and create a set of GroupPrincipal POJOs for each group for a given role destination). It might be simpler than trying to understand how the DefaultAuthorizationMap. Note that DefaultAuthorizationMap is essentially an in-memory cache of the results; you probably want to look at JNDI/LDAP at runtime to ensure up to date values. I'll be on vacation next week but I'll continue with the work after the WC finals. ;-) Great! :) (Here's hoping England actually start playing football soon... :-) -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 Sent from the ActiveMQ - Dev forum at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
Re: LDAP Authorization
On 7/17/06, James Strachan [EMAIL PROTECTED] wrote: On 7/17/06, ngcutura [EMAIL PROTECTED] wrote: I saw an entry in JIRA AMQ-376. Would this be appropriate or another one is required? Can I create entry in JIRA as unprivileged user? I didn't try, to be honest, I thought that someone from the development team is authorized to manage entries in JIRA. :-)Anyone who registers with JIRA can create new JIRA issues. Anyone can create JIRA issues... http://incubator.apache.org/activemq/support.html Though we need to assign karma to you if someone wants to assign an issue to themselves http://incubator.apache.org/activemq/contributing.html I've created a JIRA for you so we can track the patch's progress etc. http://issues.apache.org/activemq/browse/AMQ-826 -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (AMQ-826) LDAP based authorization support
LDAP based authorization support Key: AMQ-826 URL: https://issues.apache.org/activemq/browse/AMQ-826 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Patch kindly added by ngcutura - discussion thread... http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Server 2003 Support
Adrian, ActiveMQ is not officially certified on any platform, though we (ActiveMQ developers, or at least me) will certainly try to help you out on pretty much any platform we can. The best thing to do is to download the source distribution and run the test suite. It is pretty comprehensive. If any of the tests fail, or things go haywire, then please let us know and we'll definitely fix it. * Install Maven 2 ( http://maven.apache.org/ ) * Download the source distribution for the version you want to use (I suggest the most recent, 4.0.1 at this time) and unpack it. * Run mvn test in the source directory just unpacked. * Watch test results scroll by for a while (it is a pretty extensive suite, it can take some time). * If anything fails, let us know! :-) On Jul 17, 2006, at 11:41 AM, Rodriguez, Adrian wrote: Hi. I sent this message to the activemq user list but I havne't received a response. I was hoping that some devs might answer my question and give some feedback. We want to know why activemq is not officially supported on Server 2003. If it's just a matter of time (haven't gotten around to validating it on server 2003), we might be able to help out a bit. How do you guys verify that some OS is officially supported? Do you have a test suite that needs to pass? If you have a procedure that we can follow and verify that activemq works correctly on server 2003, we could give the results back to activemq if it would help the project. Thanx =) adrian /
[jira] Created: (AMQ-827) allow the usageManager to be configured in Kb or Mb to make configuration a little easier
allow the usageManager to be configured in Kb or Mb to make configuration a little easier - Key: AMQ-827 URL: https://issues.apache.org/activemq/browse/AMQ-827 Project: ActiveMQ Issue Type: Improvement Components: Broker Reporter: james strachan Assigned To: james strachan Fix For: 4.1 something like usageManager limitMb=100/ would be much simpler than having to get the calculator out to type 100 * 1024 * 1024 :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-827) allow the usageManager to be configured in Kb or Mb to make configuration a little easier
[ https://issues.apache.org/activemq/browse/AMQ-827?page=all ] james strachan resolved AMQ-827. Resolution: Fixed You can now use the setter methods / XML attributes limit=123 // bytes limitKb=123 // kilobytes limitMb=123 // megabytes allow the usageManager to be configured in Kb or Mb to make configuration a little easier - Key: AMQ-827 URL: https://issues.apache.org/activemq/browse/AMQ-827 Project: ActiveMQ Issue Type: Improvement Components: Broker Reporter: james strachan Assigned To: james strachan Fix For: 4.1 something like usageManager limitMb=100/ would be much simpler than having to get the calculator out to type 100 * 1024 * 1024 :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-828) add some XML configuration way to force the creation of certain destinations on startup
add some XML configuration way to force the creation of certain destinations on startup --- Key: AMQ-828 URL: https://issues.apache.org/activemq/browse/AMQ-828 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Assigned To: james strachan Fix For: 4.1 e.g. have some kind of XML like destinations queues queuefoo.bar/queue queuefoo.xyz/queue /queues topics topica.b.c/topic /topics /destinations -- 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
JBI User Interfaces
Does anyone know of any user interfaces that have been developed for servicemix or any other JBI applications? Specifically, some interface that helps with wiring services together through the NMR or service engines? I just don't want to re-create something that already exists. :) Thanks, Brent This e-mail is intended only for the personal and confidential use of the recipient(s) named above. It may include Blackboard confidential and proprietary information, and is not for redistribution.
JBI User interfaces
Does anyone know of any user interfaces that have been developed for servicemix or any other JBI applications? Specifically, some interface that helps with wiring services together through the NMR or service engines? I just don't want to re-create something that already exists. :) Thanks, Brent This e-mail is intended only for the personal and confidential use of the recipient(s) named above. It may include Blackboard confidential and proprietary information, and is not for redistribution.
Re: Re: Re: Re: what does a ejb-jar.xml looks like?
Well, first I found out, that in the Geronimo\repository\org\apache\geronimo\spec-folder a list of supported specifications are. There i found the geronimo-ejb_2.1_spec and geronimo-j2ee_1.4_spec folders. I hope this helps you... now my application.xml: ?xml version=1.0 encoding=UTF-8? !DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN' 'http://java.sun.com/dtd/application_1_3.dtd' application display-nameMyApp/display-name descriptionMyApp Server/description module ejbmyserver.jar/ejb /module module web web-urimyserver.war/web-uri context-root/myapp/context-root /web /module module web web-urimysample.war/web-uri context-root/sample/context-root /web /module module web web-uriwsci.war/web-uri context-root/service/context-root /web /module /application (There are also these WAR's in the EAR and some other JAR's which needn't be wrote in there... because in the other two JAR's are only some classes, as i understood) I've used this ear-file in some other application-servers and I thought, that I can use it unchanged in Geronimo, too. But this is a wrong assumption, as i know now ;-). I think that there must be done some changes... The beginning of the ejb-jar.xml looks like following: ?xml version=1.0 encoding=UTF-8? !DOCTYPE ejb-jar PUBLIC -//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN http://java.sun.com/dtd/ejb-jar_2_0.dtd; ejb-jar !-- ... -- /ejb-jar Do I have to change it too? Or is it enough to create a geronimo-ejb-jar.xml ? Thanks, mika To start with, why don't you take a look at this: http://chariotsolutions.com/geronimo/ejb.html#id2604520 There should be a DOCTYPE or xmlns at the very beginning of your ejb-jar.xml, and by comparing the values in the DOCTYPE or xmlns to the samples at that link, you should be able to figure out what version of EJB you are using. I'm not sure Geronimo supports EJB 1.0 but that's very, very old, so I think you may find you're using EJB 1.1 at a minimum. If you don't see the DOCTYPE or xmlns listed in your file, or they don't match anything at that link, can you post the first few lines of your ejb-jar.xml including the DOCTYPE or xmlns here? Also, can you post your application.xml? That would let us confirm the version of the EAR packaging it's using, and make sure it's listing the right values for your EAR. As I understand it you have 3 WARs, 1 EJB JAR, and 2 regular JARs in the EAR, so we want to make sure you have the right entries in application.xml for the EAR. Thanks, Aaron On 7/14/06, mika [EMAIL PROTECTED] wrote: 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
[jira] Created: (GERONIMO-2197) NPE when the edit link is selected on the Security Realms console page
NPE when the edit link is selected on the Security Realms console page
Key: GERONIMO-2197
URL: http://issues.apache.org/jira/browse/GERONIMO-2197
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: console
Affects Versions: 1.1
Reporter: John Sisson
Assigned To: John Sisson
Fix For: 1.1.1
h1. Problem
Cannot edit a security realm by clicking on the edit link on the Security
Realms Server Console page.
h1. Symptom
The edit link appears to be non-responsive but an exception (shown below) is
thrown and should be visible on stdout or the geronimo log.
{code}
12:19:00,863 ERROR [Servlet] Exception caught:
java.lang.NullPointerException
at java.net.URI$Parser.parse(URI.java:2946)
at java.net.URI.init(URI.java:574)
at java.net.URI.create(URI.java:836)
at
org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.actionLoadExistingRealm(SecurityRealmPortlet.java:
435)
at
org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.processAction(SecurityRealmPortlet.java:207)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
at
org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:534)
{code}
h1. Cause
The SecurityRealmPortlet.load(..) method was passing the value objectName
instead of abstractName on the request.getParameter(string) call.
h1. Solution
Corrected the parameter name to be abstractName.
h1. Workaround
Add a new security realm with a different name and then delete the old realm by
stopping it and
[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_12421535 ] Mario Ruebsam commented on GERONIMO-2188: - CommitBeforeAutoCommit = true is a setting in the database pool deployment plan and should only be set for drivers that don't commit when calling setAutoCommit on the connection and this AutoCommit value changed. further discussion about the problem here: http://www.mail-archive.com/user@geronimo.apache.org/msg03450.html JDBC drivers with that problem are: MySQL, MaxDB, PostgreSQL and for what I can see and test atm Oracle with some connection types. I don't know if the OracleXADataSource support the CommitBeforeAutoCommit setting in the deployment plan. 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
[jira] Closed: (GERONIMO-2197) NPE when the edit link is selected on the Security Realms console page
[ http://issues.apache.org/jira/browse/GERONIMO-2197?page=all ]
John Sisson closed GERONIMO-2197.
-
Fix Version/s: 1.2
Resolution: Fixed
NPE when the edit link is selected on the Security Realms console page
Key: GERONIMO-2197
URL: http://issues.apache.org/jira/browse/GERONIMO-2197
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 1.1
Reporter: John Sisson
Assigned To: John Sisson
Fix For: 1.1.1, 1.2
h1. Problem
Cannot edit a security realm by clicking on the edit link on the Security
Realms Server Console page.
h1. Symptom
The edit link appears to be non-responsive but an exception (shown below)
is thrown and should be visible on stdout or the geronimo log.
{code}
12:19:00,863 ERROR [Servlet] Exception caught:
java.lang.NullPointerException
at java.net.URI$Parser.parse(URI.java:2946)
at java.net.URI.init(URI.java:574)
at java.net.URI.create(URI.java:836)
at
org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.actionLoadExistingRealm(SecurityRealmPortlet.java:
435)
at
org.apache.geronimo.console.securitymanager.realm.SecurityRealmPortlet.processAction(SecurityRealmPortlet.java:207)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
at
org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:534)
{code}
h1. Cause
The SecurityRealmPortlet.load(..) method was
Re: org.apache.xbean-deleteMe and org/apache/xbean-crap ?
On 7/15/06, Henri Yandell [EMAIL PROTECTED] wrote: Noticed these in the m1 and m2 snapshot repositories. Any reason for them? My bad. It was a temporary workaround for bad file permissions in the repos causing me to not be able to deploy things. Since I can't chmod, I could only create a copy of the xbean directories and mv the old ones out of the way and couldn't think of anything more imaginative at the time. I can't delete them either (BTW I renamed the xbean-crap which is maybe not the most descriptive of names to xbean-delete-me). Could someone with karma zap them please? Incidentally can folks please all put something like this in their ~/.m2/settings.xml file to avoid bad permissions being created on deployments in the maven repos at Apache... (replacing jstrachan with your actual user name :) settings servers server idapache-repo/id usernamejstrachan/username directoryPermissions775/directoryPermissions filePermissions664/filePermissions /server server idapache-snapshots/id usernamejstrachan/username directoryPermissions775/directoryPermissions filePermissions664/filePermissions /server server idapache-website/id usernamejstrachan/username directoryPermissions775/directoryPermissions filePermissions664/filePermissions /server /servers /settings -- James --- http://radio.weblogs.com/0112098/
Re: djencks can you confirm the it is ok to delete the var\log\deployer-log4j.properties files proposed in GERONIMO-2117
On Jul 16, 2006, at 4:13 AM, John Sisson wrote: It is related to some changes you made ages ago. The JIRA has all the details. I'll go ahead and delete the files once I have your confirmation. AFAIK this should be fine. The configuration that used that doesn't exist any more. thanks david jencks Thanks, John
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not enough)
[
http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12421558
]
Rick McGuire commented on GERONIMO-1145:
I didn't think that the dependency workaround had ever been applied to
Geronimo, only to WAS/CE because the problem was never occuring with Geronimo
running under the Sun JVM (for whatever reasons).
The passing of the orb to StandardServant is an indirect passing. The orb
instance gets set in StandardServant downstream from this point by doing a JNDI
lookup. This fix places the appropriate orb relative to the activated bean
into the context for retrieval, rather than using a single global orb, which
would be from the first one initialized.
I've already checked other uses of Util.getORB(), and they don't have the same
sort of impact. Those uses are for occasions where an ORB instance is required
for some utility operation (data conversions, etc,). Those occurrances are
fine.
Too many ORBs (or possibly not enough)
--
Key: GERONIMO-1145
URL: http://issues.apache.org/jira/browse/GERONIMO-1145
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: OpenEJB
Affects Versions: 1.0-M5
Environment: All
Reporter: Rick McGuire
Assigned To: David Jencks
Fix For: 1.0
Attachments: orb.patch
This is sort of complicated problem to describe, but there is a problem with
the wrong ORB getting used with remote references passed in with a request.
In the current architecture, when a CORBA bean is started, it calls
Util.setORB() to register itself as the server ORB. Util.setORB() ignores
all registration calls after the first. so the first CORBABean started in the
server will determine the ORB instance returned by all
context.lookup(java:comp/ORB) calls in the server. This value is set in
StandardServant using:
// create ReadOnlyContext
Map componentContext = new HashMap(2);
componentContext.put(ORB, Util.getORB());
componentContext.put(HandleDelegate, new CORBAHandleDelegate());
try {
enc = new SimpleReadOnlyContext(componentContext);
} catch (NamingException e) {
throw new RuntimeException(e);
}
which uses the ORB object returned from Util.getORB(). This ORB value is
used for a lot during request processing, particularly when accessing
information from remote references passed to this EBJ. If there are multiple
CORBA beans configured for the server, this can create connection problems
when the beans are configured with different TSSConfigs. In the case we ran
into, an ORB instance configured for non-secure transports was trying to
(correctly) use an SSL connection to perform an operation. The connection
failed in this case because the ORB did not have the correct transport-level
security configuration needed to make the connection.
The appropriate solution would be for the StandardServant to set up the
comp/ORB value to be the ORB associated with the owning POA instance (created
in the TSSBean).
--
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-2198) CSSBean creates 2 unnecessary threads for every instance.
CSSBean creates 2 unnecessary threads for every instance. - Key: GERONIMO-2198 URL: http://issues.apache.org/jira/browse/GERONIMO-2198 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.1.1 The CSSBean creates 2 ORB instances, then spins off a thread for each that calls orb.run(). This is completely unnecessary, since orb.run() doesn't actually run anythingit just causes the thread to wait until orb.destroy() is called. These two thread instances are pure overhead, with no functional purpose. -- 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-22) Support for inverse class loading, exclusions and non overridable classes
[ http://issues.apache.org/jira/browse/XBEAN-22?page=all ] james strachan updated XBEAN-22: Fix Version/s: 2.6 (was: 2.5) Support for inverse class loading, exclusions and non overridable classes - Key: XBEAN-22 URL: http://issues.apache.org/jira/browse/XBEAN-22 Project: XBean Issue Type: New Feature Components: server Affects Versions: 2.3 Reporter: Guillaume Nodet Fix For: 2.6 Attachments: XBEAN-22.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2198) CSSBean creates 2 unnecessary threads for every instance.
[ http://issues.apache.org/jira/browse/GERONIMO-2198?page=all ] Rick McGuire updated GERONIMO-2198: --- Attachment: geronimo-2198.diff CSSBean creates 2 unnecessary threads for every instance. - Key: GERONIMO-2198 URL: http://issues.apache.org/jira/browse/GERONIMO-2198 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.1.1 Attachments: geronimo-2198.diff The CSSBean creates 2 ORB instances, then spins off a thread for each that calls orb.run(). This is completely unnecessary, since orb.run() doesn't actually run anythingit just causes the thread to wait until orb.destroy() is called. These two thread instances are pure overhead, with no functional purpose. -- 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-2198) CSSBean creates 2 unnecessary threads for every instance.
[ http://issues.apache.org/jira/browse/GERONIMO-2198?page=all ] Rick McGuire updated GERONIMO-2198: --- Patch Info: [Patch Available] CSSBean creates 2 unnecessary threads for every instance. - Key: GERONIMO-2198 URL: http://issues.apache.org/jira/browse/GERONIMO-2198 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Rick McGuire Fix For: 1.1.1 Attachments: geronimo-2198.diff The CSSBean creates 2 ORB instances, then spins off a thread for each that calls orb.run(). This is completely unnecessary, since orb.run() doesn't actually run anythingit just causes the thread to wait until orb.destroy() is called. These two thread instances are pure overhead, with no functional purpose. -- 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-2167) deployer.jar not cleaning up properly during redeploy and undeploy
[
http://issues.apache.org/jira/browse/GERONIMO-2167?page=comments#action_12421573
]
Kevan Miller commented on GERONIMO-2167:
Leonard, thanks for the source.
I'm certain that the following line of code from
ContextListener.contextInitialized() is at the root of your problem:
InputStreamReader in = new
InputStreamReader(getClass().getClassLoader().getResourceAsStream(db.sql));
db.sql is the file that's being locked by Windows. Right now, your
contextDestroyed() method is not doing anything. I'd prefer to see it closing
your HSQL connection and insuring that the above InputStreamReader has been
closed. I'm pretty confident that if you close the above InputStream, undeploy
will work properly...
I'm leaving the jira open a bit longer, it's possible that we could/should
avoid this situation. Geronimo should be able to deploy/undeploy an app, even
if it's not well-behaved. I'm going to think about this...
deployer.jar not cleaning up properly during redeploy and undeploy
--
Key: GERONIMO-2167
URL: http://issues.apache.org/jira/browse/GERONIMO-2167
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.1
Environment: Win32/XP SP1
Sun JDK 1.5_06
Reporter: Leonard Wu
Assigned To: Kevan Miller
Fix For: 1.1.1
Attachments: dwr-demo.war, jw-0620-dwr.zip
deployment using deploy.jar doesn't appear to clean up correctly.
first deploy always works. subsequent re-deploy and un-deploy are problematic.
following illustrates the full sequence of events as i had encountered:
--
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager deploy D:/work/SERVER/dwr-demo.war
Deployed littleoldme/dwrdemo/1.1/war @ http://vaio:8080/dwr-demo
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Deployed littleoldme/dwrdemo/1.1/war
Started littleoldme/dwrdemo/1.1/war
Redeployed littleoldme/dwrdemo/1.1/war
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Error: Operation failed:
org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException:
Configuration already exists: littleoldme/dwrdemo/1.1/war
Configuration already exists: littleoldme/dwrdemo/1.1/war
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager undeploy littleoldme/dwrdemo/1.1/war
Error: littleoldme/dwrdemo/1.1/war does not appear to be a the name
of a module available on the selected server. Perhaps it has already
been stopped or undeployed? If you're trying to specify a
TargetModuleID, use the syntax TargetName|ModuleName instead. If
you're not sure what's running, try the list-modules command.
--
While in this broken state, i'm able to recover by manually removing the
${geronimo}/repository/littleoldme directory and removing the one line in
${geronimo}/var/config/config.xml that says
module load=false name=littleoldme/dwrdemo/1.1/war/
However, this only gets me to a fresh beginning, and then the whole sequence
starts again as I repeat (re/un)deploying.
--
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
Unassigned Patches: week of 07-17-2006
Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 25 items DATE UPDATED KEY SUMMARY Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Feb 25 2006 - GERONIMO-1652 - EJBModuleImpl.getEJBs() always return an empty array Mar 7 2006 - GERONIMO-1657 - CommandSupport doesn't bubble up the exception. Prints stacktrace. Mar 21 2006 - GERONIMO-1757 - rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction Apr 10 2006 - GERONIMO-1804 - The name of JNDI/RMI service provider is hardcoded in the sources. Apr 11 2006 - GERONIMO-1826 - Naming tests might not work on non-Sun VMs. Apr 12 2006 - GERONIMO-1833 - Non-public Sun classes dependencies in tests Apr 13 2006 - GERONIMO-1840 - NamingPropertiesTest is not compatible with non-Sun VMs. Apr 26 2006 - GERONIMO-1911 - HTTPS algorithm=Default is not preserved after the server is started May 26 2006 - GERONIMO-2064 - Mail archive links in the Welcome portlet should use the redirects at geronimo.apache.org Jun 6 2006 - GERONIMO-1813 - When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory Jun 30 2006 - GERONIMO-1196 - Keystore portlet: Viewing trusted certificate results in an error Jul 6 2006 - GERONIMO-2066 - Openejb migration to M2 Jul 16 2006 - GERONIMO-2073 - Copyright date in the console needs to be updated Jul 16 2006 - GERONIMO-1182 - Connector portlet delete challenge Jul 16 2006 - GERONIMO-1906 - Cannot add a new connector using ActiveMQManagerGBean Jul 16 2006 - GERONIMO-1967 - /remote-deploy url link throws Error 404. Jul 16 2006 - GERONIMO-2072 - Client-Deployer config is using wrong/hardcoded commons-primitives version Jul 16 2006 - GERONIMO-1451 - A new TCP listener for ActiveMQ is not persisting across server startups Jul 16 2006 - GERONIMO-1163 - improve jmx debug console Jul 16 2006 - GERONIMO-1130 - Implement WebServer Manager (statistics gathering/reporting) management interface Jul 16 2006 - GERONIMO-1341 - POP3 Implementation
[jira] Commented: (GERONIMO-1695) CORBA for EJB with Local interface only causes NPE
[ http://issues.apache.org/jira/browse/GERONIMO-1695?page=comments#action_12421590 ] Rick McGuire commented on GERONIMO-1695: The SessionBuilder and EntityBuilder changes are still there, but the CMPEntityBuilder change was not. Attaching patches for these two versions. 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 Attachments: GERONIMO-1695.diff-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] Updated: (GERONIMO-1695) CORBA for EJB with Local interface only causes NPE
[ http://issues.apache.org/jira/browse/GERONIMO-1695?page=all ] Rick McGuire updated GERONIMO-1695: --- Attachment: GERONIMO-1695.diff-1.1.1 This is the change for the 1.1.1 version. 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 Attachments: GERONIMO-1695.diff-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] Updated: (GERONIMO-1695) CORBA for EJB with Local interface only causes NPE
[ http://issues.apache.org/jira/browse/GERONIMO-1695?page=all ] Rick McGuire updated GERONIMO-1695: --- Attachment: GERONIMO-1695.diff-1.2 1.2 version. 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 Attachments: GERONIMO-1695.diff-1.1.1, GERONIMO-1695.diff-1.2 I have an EJB with a local interface and I tried applying CORBA settings. It blows up during deployment. My guess is that it wants a remote interface to be there, but somehow, the checks in StandardServant:126 are not working and the interface just comes up as null. Caused by: java.lang.NullPointerException at org.openejb.corba.util.Util.getAllInterfaces(Util.java:593) at org.openejb.corba.util.Util.getAllMethods(Util.java:815) at org.openejb.corba.util.Util.iiopMap(Util.java:608) at org.openejb.corba.util.Util.mapOperationToMethod(Util.java:604) at org.openejb.corba.StandardServant.init(StandardServant.java:135) at org.openejb.corba.StandardServant.init(StandardServant.java:116) at org.openejb.corba.Adapter.init(Adapter.java:100) ... 67 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: LDAP Authorization
James.Strachan wrote: Sounds great! I didn't see an attachment - I wonder it might be easier if you raised a JIRA and attached your zip to the JIRA issue? Attachment is hyperlinked below sentnece Attached is a zip archive with 4 files: in original post. (LdapAuth.zip is hyperlinked; clicking this link opens file download.) I saw an entry in JIRA AMQ-376. Would this be appropriate or another one is required? Can I create entry in JIRA as unprivileged user? I didn't try, to be honest, I thought that someone from the development team is authorized to manage entries in JIRA. :-) Regards, NGC On 7/15/06, ngcutura [EMAIL PROTECTED] wrote: Hi all, I followed James' advice and created simple LDAPAuthorizationMap. It has no support for wildcards or composite destinations at the moment. Attached is a zip archive with 4 files: LdapAuth.zip - LDAPAuthorizationMap.java (module code) - LDAPAuthorizationMapTest.java (module test) - LDAPAuthorizationMap.properties (list of module properties) - AMQAuth.ldif (sample directory used for testing) Module works through JUnit tests. To run the tests you need to setup a directory. I used ApacheDS; export of my sample directory is in the file AMQAuth.ldif. Contents of this file is also present in LDAPAuthorizationMapTest.java. I am not familiar with Spring and I was not able to deduce how to specify module properties in AMQ XML config file. I need help with this and I would very much appreciate the following: - given the LDAPAuthorizationMap.properties file produce XML file - given the LDAPAuthorizationMap.java add code changes to accept properties from XML file above I am pretty much sure that my choice of constructor taking Map as argument is inappropraite but having no knowledge of Spring one choice was as good as another for me. Regards, NGC James.Strachan wrote: On 6/29/06, ngcutura [EMAIL PROTECTED] wrote: Thank you for reply. There is no bean class=com.acme... ... in security example but this is quite important. Thats just a way to instantiate some JavaBean using regular Spring style syntax. Is there some default class like DefaultAuthorizationMap? Yes - by all means derive from that if you want. What would this declaration be exactly for the security example you referred to? I think I can manage AuthorizationEntry by subclassing it or adding another parse() method. You could ignore the DefaultAuthorizationMap/AuthorizationEntry entirely and just walk JNDI/LDAP and create a set of GroupPrincipal POJOs for each group for a given role destination). It might be simpler than trying to understand how the DefaultAuthorizationMap. Note that DefaultAuthorizationMap is essentially an in-memory cache of the results; you probably want to look at JNDI/LDAP at runtime to ensure up to date values. I'll be on vacation next week but I'll continue with the work after the WC finals. ;-) Great! :) (Here's hoping England actually start playing football soon... :-) -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494 Sent from the ActiveMQ - Dev forum at Nabble.com. -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5359733 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Commented: (GERONIMO-1145) Too many ORBs (or possibly not enough)
[
http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12421596
]
Ted Kirby commented on GERONIMO-1145:
-
Thanks Rick.
I am still confused about David's fix of [05/Dec/05 10:32 PM].
When you say This fix places the appropriate orb relative to the activated
bean into the context for retrieval, rather than using a single global orb,
which would be from the first one initialized., are you talking about David's
fix of [05/Dec/05 10:32 PM]?
It still seems that a key piece of it is missing, namely:
componentContext.put(ORB, Util.getORB());
---
componentContext.put(ORB, orb);
Otherwise, I don't see that that fix accomplishes anything.
Too many ORBs (or possibly not enough)
--
Key: GERONIMO-1145
URL: http://issues.apache.org/jira/browse/GERONIMO-1145
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: OpenEJB
Affects Versions: 1.0-M5
Environment: All
Reporter: Rick McGuire
Assigned To: David Jencks
Fix For: 1.0
Attachments: orb.patch
This is sort of complicated problem to describe, but there is a problem with
the wrong ORB getting used with remote references passed in with a request.
In the current architecture, when a CORBA bean is started, it calls
Util.setORB() to register itself as the server ORB. Util.setORB() ignores
all registration calls after the first. so the first CORBABean started in the
server will determine the ORB instance returned by all
context.lookup(java:comp/ORB) calls in the server. This value is set in
StandardServant using:
// create ReadOnlyContext
Map componentContext = new HashMap(2);
componentContext.put(ORB, Util.getORB());
componentContext.put(HandleDelegate, new CORBAHandleDelegate());
try {
enc = new SimpleReadOnlyContext(componentContext);
} catch (NamingException e) {
throw new RuntimeException(e);
}
which uses the ORB object returned from Util.getORB(). This ORB value is
used for a lot during request processing, particularly when accessing
information from remote references passed to this EBJ. If there are multiple
CORBA beans configured for the server, this can create connection problems
when the beans are configured with different TSSConfigs. In the case we ran
into, an ORB instance configured for non-secure transports was trying to
(correctly) use an SSL connection to perform an operation. The connection
failed in this case because the ORB did not have the correct transport-level
security configuration needed to make the connection.
The appropriate solution would be for the StandardServant to set up the
comp/ORB value to be the ORB associated with the owning POA instance (created
in the TSSBean).
--
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-1145) Too many ORBs (or possibly not enough)
[
http://issues.apache.org/jira/browse/GERONIMO-1145?page=comments#action_12421600
]
Rick McGuire commented on GERONIMO-1145:
I'm sorry, I misread your ealier comment. I thought you were saying that the
change didn't seem to be doing anything, not that the change was missing. Yes,
I believe you are correct. I'm not sure how/when that part of the fix got
deleted.
Too many ORBs (or possibly not enough)
--
Key: GERONIMO-1145
URL: http://issues.apache.org/jira/browse/GERONIMO-1145
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: OpenEJB
Affects Versions: 1.0-M5
Environment: All
Reporter: Rick McGuire
Assigned To: David Jencks
Fix For: 1.0
Attachments: orb.patch
This is sort of complicated problem to describe, but there is a problem with
the wrong ORB getting used with remote references passed in with a request.
In the current architecture, when a CORBA bean is started, it calls
Util.setORB() to register itself as the server ORB. Util.setORB() ignores
all registration calls after the first. so the first CORBABean started in the
server will determine the ORB instance returned by all
context.lookup(java:comp/ORB) calls in the server. This value is set in
StandardServant using:
// create ReadOnlyContext
Map componentContext = new HashMap(2);
componentContext.put(ORB, Util.getORB());
componentContext.put(HandleDelegate, new CORBAHandleDelegate());
try {
enc = new SimpleReadOnlyContext(componentContext);
} catch (NamingException e) {
throw new RuntimeException(e);
}
which uses the ORB object returned from Util.getORB(). This ORB value is
used for a lot during request processing, particularly when accessing
information from remote references passed to this EBJ. If there are multiple
CORBA beans configured for the server, this can create connection problems
when the beans are configured with different TSSConfigs. In the case we ran
into, an ORB instance configured for non-secure transports was trying to
(correctly) use an SSL connection to perform an operation. The connection
failed in this case because the ORB did not have the correct transport-level
security configuration needed to make the connection.
The appropriate solution would be for the StandardServant to set up the
comp/ORB value to be the ORB associated with the owning POA instance (created
in the TSSBean).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2117) Remove deployer-log4j.properties files - they are no longer used
[ http://issues.apache.org/jira/browse/GERONIMO-2117?page=all ] John Sisson closed GERONIMO-2117. - Fix Version/s: 1.2 Resolution: Fixed Remove deployer-log4j.properties files - they are no longer used Key: GERONIMO-2117 URL: http://issues.apache.org/jira/browse/GERONIMO-2117 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1 Reporter: John Sisson Assigned To: John Sisson Priority: Trivial Fix For: 1.1.1, 1.2 Description The Geronimo 1.1 distribution contains a var\log\deployer-log4j.properties file but the file is not used. Symptom Changes to the var\log\deployer-log4j.properties file do not have any effect. Cause References to the file were removed as part of changes for GERONIMO-1306, remove modules/assembly GERONIMO-1294 remove offline capability from online deployment tool ( http://svn.apache.org/viewcvs?rev=354830view=rev ), but the var\log\.deployer-log4j.properties file wasn't deleted as part of those changes. Solution The var\log\deployer-log4j.properties file will be removed from future distributions. Workaround You can safely delete the var\log\deployer-log4j.properties 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
Re: LDAP Authorization
On 7/17/06, ngcutura [EMAIL PROTECTED] wrote: James.Strachan wrote: Sounds great! I didn't see an attachment - I wonder it might be easier if you raised a JIRA and attached your zip to the JIRA issue? Attachment is hyperlinked below sentnece Attached is a zip archive with 4 files: in original post. (LdapAuth.zip is hyperlinked; clicking this link opens file download.) Ah - it seems to have got stripped from the emails (or at least gmail stripped it) but its visible on nabble.com. I saw an entry in JIRA AMQ-376. Would this be appropriate or another one is required? Can I create entry in JIRA as unprivileged user? I didn't try, to be honest, I thought that someone from the development team is authorized to manage entries in JIRA. :-)Anyone who registers with JIRA can create new JIRA issues. Anyone can create JIRA issues... http://incubator.apache.org/activemq/support.html Though we need to assign karma to you if someone wants to assign an issue to themselves http://incubator.apache.org/activemq/contributing.html -- James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-2199) Key portion of Geronimo-1145 appears have gotten lost.
[ http://issues.apache.org/jira/browse/GERONIMO-2199?page=all ] Rick McGuire updated GERONIMO-2199: --- Attachment: GERONIMO-2199.diff-1.2 Key portion of Geronimo-1145 appears have gotten lost. -- Key: GERONIMO-2199 URL: http://issues.apache.org/jira/browse/GERONIMO-2199 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Rick McGuire Priority: Minor Fix For: 1.2, 1.1.1 Attachments: GERONIMO-2199.diff-1.1.1, GERONIMO-2199.diff-1.2 A key piece of the patch for GERONIMO-1145 was left out when the patch was applied. The following change needs to be added: - componentContext.put(ORB, Util.getORB()); + componentContext.put(ORB, orb); Without this change, the rest of the patch is meaningless. -- 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-2199) Key portion of Geronimo-1145 appears have gotten lost.
[ http://issues.apache.org/jira/browse/GERONIMO-2199?page=all ] Rick McGuire updated GERONIMO-2199: --- Attachment: GERONIMO-2199.diff-1.1.1 Key portion of Geronimo-1145 appears have gotten lost. -- Key: GERONIMO-2199 URL: http://issues.apache.org/jira/browse/GERONIMO-2199 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Rick McGuire Priority: Minor Fix For: 1.2, 1.1.1 Attachments: GERONIMO-2199.diff-1.1.1, GERONIMO-2199.diff-1.2 A key piece of the patch for GERONIMO-1145 was left out when the patch was applied. The following change needs to be added: - componentContext.put(ORB, Util.getORB()); + componentContext.put(ORB, orb); Without this change, the rest of the patch is meaningless. -- 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
Transaction isolation level in TranQL
Hi, Matt, What are the perspectives of having the capability to specify the transaction isolation level in TranQL? I'm awaiting this feature eagerly, as it looks like a key to a successful SPECjAppServer2004 run... Recently you said (http://www.mail-archive.com/user@geronimo.apache.org/msg03421.html) that this feature may be a part of TranQL 1.3.1, which is gonna be a part of Geronimo 1.1.1, as far as I understand. Am I right? Thank you! Vasily Zakharov Intel Middleware Products Division
[jira] Updated: (GERONIMO-1557) When you enter the url of a web service in the console You should get a page showing the service name
[ http://issues.apache.org/jira/browse/GERONIMO-1557?page=all ] Donald Woods updated GERONIMO-1557: --- Fix Version/s: 1.1.1 (was: 1.2) Assignee: David Jencks David, can you apply this patch, which helps the Axis support behave more like what a Tomcat + Axis user would expect? I've applied it to a local copt of the 1.1 branch and tried it quickly with Daytrader. When you enter the url of a web service in the console You should get a page showing the service name - Key: GERONIMO-1557 URL: http://issues.apache.org/jira/browse/GERONIMO-1557 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: webservices Affects Versions: 1.0 Environment: All Reporter: Manu T George Assigned To: David Jencks Priority: Minor Fix For: 1.1.1 Attachments: AxisServiceBuilder.patch, AxisServiceBuilder.patch, AxisWebServiceContainer.patch, AxisWebServiceContainer.patch, AxisWebServiceContainer.patch When you type the URL of a web service in a browser without the ?wsdl parameter what happens is that a SOAPFault is thrown. Instead we should show a HTML page with the message This is a web service followed by the service name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2128) Allow user to specify the Isolation Level for a CMP bean's SQL access
[ http://issues.apache.org/jira/browse/GERONIMO-2128?page=all ] Matt Hogstrom updated GERONIMO-2128: Fix Version/s: 1.2 (was: 1.1.x) Allow user to specify the Isolation Level for a CMP bean's SQL access - Key: GERONIMO-2128 URL: http://issues.apache.org/jira/browse/GERONIMO-2128 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Reporter: Matt Hogstrom Fix For: 1.2 Currently CMP beans all execute in the default isolation level of the datasource. This means that in many situations higher level locks are required for the database access than are required. This improvement will allow the user to specify a new attribute on a CMP entity bean isolation-level that will be the isolation level used for database access on this entity bean. This will require updates to OpenEJB and TranQL. -- 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-2129) Allow user to specify the pool size for Stateless Session beans
[ http://issues.apache.org/jira/browse/GERONIMO-2129?page=all ] Matt Hogstrom updated GERONIMO-2129: Fix Version/s: 1.2 (was: 1.1.x) Allow user to specify the pool size for Stateless Session beans --- Key: GERONIMO-2129 URL: http://issues.apache.org/jira/browse/GERONIMO-2129 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Reporter: Matt Hogstrom Fix For: 1.2 OpenEJB has code implemented to Pool Stateless session beans. This support is currently hardcoded to a cache size of one which eliminates any performance benefit of caching. A new attribute will be added to the OpenEJB XSD that will allow the user to specify the pool size to be used for a deployed stateless session bean. The attribute will be poolsize and will take an integer value as its argument. -- 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-2127) Expose the ability to use Select for Update on CMP entity beans
[ http://issues.apache.org/jira/browse/GERONIMO-2127?page=all ] Matt Hogstrom updated GERONIMO-2127: Fix Version/s: 1.2 (was: 1.1.x) Expose the ability to use Select for Update on CMP entity beans --- Key: GERONIMO-2127 URL: http://issues.apache.org/jira/browse/GERONIMO-2127 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Environment: All Reporter: Matt Hogstrom Fix For: 1.2 Currently TranQL supports the generation sql to execute a select for update. Unfortunately, OpenEJB does not expose the ability in the current XSD to support this. As a result the CMP implementation we have does pass CTS but lacks the ability to deploy an application that is performant and provides for data consistency. This improvement will add an attribute into the XSD for OpenEJB so a new attribute will be added select-for-update that is an indicator to use a select for update on a query so database locking can be employed. Changes will be made to TranQL (Syntax Factories) to create the correct SQL as well as OpenEJB's CMP builders to honor the request. -- 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
The most important thing to me is to be able to deploy Jars and Wars into Geronimo, but starting and stoping it could be useful for me though. What i have now is a simple Jar with a simple SessionBean. Donald Woods wrote: 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
Re: [jira] Updated: (GERONIMO-2199) Key portion of Geronimo-1145 appears have gotten lost.
Rick, You seem to be attaching a lot of patches to Jira's for what seem to be bug fixes. Is there a reason why you aren't committing them? --kevan On Jul 17, 2006, at 9:10 AM, Rick McGuire (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2199?page=all ] Rick McGuire updated GERONIMO-2199: --- Attachment: GERONIMO-2199.diff-1.1.1 Key portion of Geronimo-1145 appears have gotten lost. -- Key: GERONIMO-2199 URL: http://issues.apache.org/jira/browse/ GERONIMO-2199 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Rick McGuire Priority: Minor Fix For: 1.2, 1.1.1 Attachments: GERONIMO-2199.diff-1.1.1, GERONIMO-2199.diff-1.2 A key piece of the patch for GERONIMO-1145 was left out when the patch was applied. The following change needs to be added: - componentContext.put(ORB, Util.getORB()); + componentContext.put(ORB, orb); Without this change, the rest of the patch is meaningless. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/ Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira
Re: [jira] Updated: (GERONIMO-2199) Key portion of Geronimo-1145 appears have gotten lost.
Kevan Miller wrote: Rick, You seem to be attaching a lot of patches to Jira's for what seem to be bug fixes. Is there a reason why you aren't committing them? Because I don't yet have commit privileges for openejb. Rick --kevan On Jul 17, 2006, at 9:10 AM, Rick McGuire (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2199?page=all ] Rick McGuire updated GERONIMO-2199: --- Attachment: GERONIMO-2199.diff-1.1.1 Key portion of Geronimo-1145 appears have gotten lost. -- Key: GERONIMO-2199 URL: http://issues.apache.org/jira/browse/GERONIMO-2199 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Rick McGuire Priority: Minor Fix For: 1.2, 1.1.1 Attachments: GERONIMO-2199.diff-1.1.1, GERONIMO-2199.diff-1.2 A key piece of the patch for GERONIMO-1145 was left out when the patch was applied. The following change needs to be added: - componentContext.put(ORB, Util.getORB()); + componentContext.put(ORB, orb); Without this change, the rest of the patch is meaningless. --This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (GERONIMO-2199) Key portion of Geronimo-1145 appears have gotten lost.
Doh! Sorry, obviously didn't look at the patches or read the jira closely... I'll have a look at them this afternoon. --kevan On Jul 17, 2006, at 10:48 AM, Rick McGuire wrote: Kevan Miller wrote: Rick, You seem to be attaching a lot of patches to Jira's for what seem to be bug fixes. Is there a reason why you aren't committing them? Because I don't yet have commit privileges for openejb. Rick --kevan On Jul 17, 2006, at 9:10 AM, Rick McGuire (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2199?page=all ] Rick McGuire updated GERONIMO-2199: --- Attachment: GERONIMO-2199.diff-1.1.1 Key portion of Geronimo-1145 appears have gotten lost. -- Key: GERONIMO-2199 URL: http://issues.apache.org/jira/browse/ GERONIMO-2199 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Rick McGuire Priority: Minor Fix For: 1.2, 1.1.1 Attachments: GERONIMO-2199.diff-1.1.1, GERONIMO-2199.diff-1.2 A key piece of the patch for GERONIMO-1145 was left out when the patch was applied. The following change needs to be added: - componentContext.put(ORB, Util.getORB()); + componentContext.put(ORB, orb); Without this change, the rest of the patch is meaningless. --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
[m2 build] unable to deploy remote-deploy-* configs
I am trying to get remote-deploy-jetty and remote-deploy-tomcat configs into the m2 build and it is failing due to packaging/deploy error. (Anita, Jason, I did get some info off the patches in G-2067 but that didn't help me too much). It fails in 1.2 because the deployer in 1.2 has only the ServiceBuilder available to it. The same config installs successfully in a 1.1 build. In 1.1, the deployer has ServiceBuilder and EarConfigBuilder available to it. The latter successfully processes the remote-deploy's plan and deploys it. The EARConfigBuilder is missing in the collection of builders available to the deployer in 1.2. I'm trying to find out what/who puts the builders in the collection there. If anybody knows, please speak up. Cheers Prasad
Re: Virtual Topics (was Re: Failover topic subscribers)
In order for virtual topics to work, getDestinations(.. ) needs to return the virtual destinations. This doesnt happen now since Queues prefixed with ActiveMQ.Virtual don't ever get added to the Destinations Set (nothing actually sends them a message). I'm looking for the place in the broker change where I could change this behavior. Any ideas? RegionBroker looks like it does most of the work. -- View this message in context: http://www.nabble.com/Re%3A-Virtual-Topics-%28was-Re%3A-Failover-topic-subscribers%29-tf1942508.html#a5364439 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Virtual Topics (was Re: Failover topic subscribers)
Or AbstractRegion.. I think I can get tthis to work without messing up any of the persistence logic. -- View this message in context: http://www.nabble.com/Re%3A-Virtual-Topics-%28was-Re%3A-Failover-topic-subscribers%29-tf1942508.html#a5364499 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Does each module really need LICENSE.txt and NOTICE.txt?
Well, I think adding the files to every module is potentially a problem. I think the release should have a central place all modules derive their LICENSE file from. The NOTICIES file is a different animal. Jason Dillon wrote: If we want to keep these guys in the jars, then we should move them to their standard src/main/resources/META-INF/* locations so that they get picked up automatically. --jason On Jul 16, 2006, at 5:27 PM, John Sisson wrote: Jason Dillon wrote: Um... when were these ever included in the module's jars before? --jason On Jul 16, 2006, at 5:04 PM, John Sisson wrote: Jason Dillon wrote: Does each module really need LICENSE.txt and NOTICE.txt? Or can we just have this at the top-level of the project? I'd rather have less duplicate files to maintain... Any comments? --jason I think they are needed as each downloadable jar (which each module has) should contain the license and notice files. Same with source archives, which AFAIK maven can produce for each individual module for use by IDE debuggers etc. John I just checked and if you look at geronimo-activation-1.1.jar it should contain META-INF\LICENSE.TXT . It is a problem that the NOTICE.txt file isn't also included. We should add a JIRA for the 1.1.1 release for that. John
Re: Transaction isolation level in TranQL
Vasily, It is already part of TranQL. What we need is a change to OpenEJB to allow the specification of Isolation Level so TranQL can generate the right code. Let me start a new thread to see if we can get this in 1.1.1. Matt Zakharov, Vasily M wrote: Hi, Matt, What are the perspectives of having the capability to specify the transaction isolation level in TranQL? I'm awaiting this feature eagerly, as it looks like a key to a successful SPECjAppServer2004 run... Recently you said (http://www.mail-archive.com/user@geronimo.apache.org/msg03421.html) that this feature may be a part of TranQL 1.3.1, which is gonna be a part of Geronimo 1.1.1, as far as I understand. Am I right? Thank you! Vasily Zakharov Intel Middleware Products Division
Re: Does each module really need LICENSE.txt and NOTICE.txt?
On Jul 17, 2006, at 1:06 PM, Matt Hogstrom wrote: Well, I think adding the files to every module is potentially a problem. I think the release should have a central place all modules derive their LICENSE file from. The NOTICIES file is a different animal. Matt, What modules are you referring to? All of our generated jar files (.e.g geronimo-kernel-1.1.jar) should contain LICENSE and NOTICE files. Hrrm, I just looked at two 1.1 jars and they only contain LICENSE files. We also need a LICENSE and NOTICE file at the base of our distributions. These should contain all necessary license and notice information for all of the Geronimo code built and included in our distribution. The license and notice file also need to contain license and notice information for all jar files, or other artifacts, that we include in our distribution (e.g. asm jar, castor jar, etc...). Or, are you instead referring to modules as in CAR's? If so, then they are a different animal. However, I don't think we're released from any licensing requirements. Given the guidelines in http://www.apache.org/dev/release.html#what- must-every-release-contain (see the Can I distribute a raw artifact? section at the bottom), I think that any downloadable artifact (distribution, car, jar, war, ear, etc) that we release to ibiblio should have appropriate license and notice files (alternatively, we stop releasing the artifact). --kevan Jason Dillon wrote: If we want to keep these guys in the jars, then we should move them to their standard src/main/resources/META-INF/* locations so that they get picked up automatically. --jason On Jul 16, 2006, at 5:27 PM, John Sisson wrote: Jason Dillon wrote: Um... when were these ever included in the module's jars before? --jason On Jul 16, 2006, at 5:04 PM, John Sisson wrote: Jason Dillon wrote: Does each module really need LICENSE.txt and NOTICE.txt? Or can we just have this at the top-level of the project? I'd rather have less duplicate files to maintain... Any comments? --jason I think they are needed as each downloadable jar (which each module has) should contain the license and notice files. Same with source archives, which AFAIK maven can produce for each individual module for use by IDE debuggers etc. John I just checked and if you look at geronimo-activation-1.1.jar it should contain META-INF\LICENSE.TXT . It is a problem that the NOTICE.txt file isn't also included. We should add a JIRA for the 1.1.1 release for that. John
[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_12421681 ] Matt Hogstrom commented on GERONIMO-2188: - Thanks Mario, I was thinking about it over the weekend and I decided the change was not relevant. Since people can tweak the property they should do that ... I'm going to reverse the change. Might be nice to put out a warning though if we know this is an Oracle driver instead. 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
[jira] Created: (GERONIMO-2200) SMTP debug output echos portions of the output twice.
SMTP debug output echos portions of the output twice. - Key: GERONIMO-2200 URL: http://issues.apache.org/jira/browse/GERONIMO-2200 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: mail Affects Versions: 1.1.1, 1.2 Reporter: Rick McGuire Assigned To: Rick McGuire Priority: Trivial Fix For: 1.1.1, 1.2 If debug mode is enabled for SMTP, portions of the output stream are getting written to the debug stream twice. For example, a QUIT command shows up as QUITQUIT -- 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
Server 2003 Support
Hi. I sent this message to the activemq user list but I havne't received a response. I was hoping that some devs might answer my question and give some feedback. We want to know why activemq is not officially supported on Server 2003. If it's just a matter of time (haven't gotten around to validating it on server 2003), we might be able to help out a bit. How do you guys verify that some OS is officially supported? Do you have a test suite that needs to pass? If you have a procedure that we can follow and verify that activemq works correctly on server 2003, we could give the results back to activemq if it would help the project. Thanx =) adrian /
[jira] Resolved: (GERONIMO-2200) SMTP debug output echos portions of the output twice.
[ http://issues.apache.org/jira/browse/GERONIMO-2200?page=all ] Rick McGuire resolved GERONIMO-2200. Resolution: Fixed 1.1.1: Committed revision 422788. 1.2 Committed revision 422790. SMTP debug output echos portions of the output twice. - Key: GERONIMO-2200 URL: http://issues.apache.org/jira/browse/GERONIMO-2200 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Affects Versions: 1.2, 1.1.1 Reporter: Rick McGuire Assigned To: Rick McGuire Priority: Trivial Fix For: 1.1.1, 1.2 If debug mode is enabled for SMTP, portions of the output stream are getting written to the debug stream twice. For example, a QUIT command shows up as QUITQUIT -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
1.1.1 Release Plan
All, I've been travelling quite a bit over the past few weeks and have been a bit delinquent on getting 1.1.1 defined and ready to go. I see that Alan has been a busy little beaver and moving JIRAs out from 1.1.1 to the fateful 1.x release to help further refine the scope of 1.1.1. I'd like to get the content formalized and propose a timeline for getting the release out. *Goal* 1.1.1 is a bug fix release and is intended to incorporate a number of latent issues that are pending in Geronimo that didn't make 1.1. These are bug fixes and not feature improvements. *Roles* Matt Hogstrom is the primary release manager for 1.1.1 and Alan Cabrera is riding shotgun. *Timeframe* Branch 1.1 to 1.1.1 on or around July 28th. The date is a guideline but put out there to help people set expectations about what can be accomplished. *Management* JIRA will be used to manage 1.1.1. As JIRAs are closed we'll manage the release down to 0 JIRA's. It may be that we decided to defer JIRA's based on available interest to resolve issues so that we'll balance the date and the content so we can turn this out as quickly as possible. *Scope* The changes here are focused on bug fixes so there should not be any RTC changes required here. The goal is to improve stability. *Content* There are 25 JIRA's currently slated for 1.1.1. In no particular order they are: GERONIMO-1960 Bad GBean reference isn't caught during deployment GERONIMO-1492 Many org/apache/geronimo configIds still live in source tree GERONIMO-1524 DB pool portlet should let you select multiple driver JARs GERONIMO-1695 CORBA for EJB with Local interface only causes NPE GERONIMO-1476 Changes to default log4j.rootCategory are not dynamic GERONIMO-1917 repository doesn't deal well with case insensitive file systems GERONIMO-1996 Serialization failure during deployment leaves a config.ser in the repository but doesn't write a config.info causing problems later. GERONIMO-2007 Avoid Classloader warnings generated by BasicProxyManager GERONIMO-1817 Test a Login while adding LDAP Realm fails with NullPointerException GERONIMO-2186 Editing of Connection Pools other than Derby from console not working GERONIMO-2196 Incorrect dependency loaded during Geronimo build GERONIMO-2080 Create a Geronimo Bug Guidelines Page GERONIMO-2169 Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) GERONIMO-2170 Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories GERONIMO-2198 CSSBean creates 2 unnecessary threads for every instance. GERONIMO-2167 deployer.jar not cleaning up properly during redeploy and undeploy GERONIMO-1791 LDAP Security Realm created via Console can fail deployment GERONIMO-1959 Console: plugin % complete shoudl reset to 0 while preparing a download GERONIMO-1716 Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console GERONIMO-2199 Key portion of Geronimo-1145 appears have gotten lost. GERONIMO-1557 When you enter the url of a web service in the console You should get a page showing the service name GERONIMO-2136 Remove/Update licenses displayed in about page of console GERONIMO-2138 Configuration jsp-examples-tomcat includes Jetty dependencies GERONIMO-1037 Clicking on uninstall link in Applications management pages deletes the configuration without any confirmation from user GERONIMO-1810 Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message Each of these issues are assigned to folks who I believe are planning on getting the work completed. Personally, I have to go back through the ones that we're moved out and retrieve a few for myself. If anyone else is interested in getting a big fix into 1.1.1 please assign 1.1.1 as the fix version and assign the JIRA to yourself. Let the coding begin. I'll check the existing JIRA's for patches and start reviewing and applying them for folks that are not currently committers. Thanks Matt
Re: Does each module really need LICENSE.txt and NOTICE.txt?
I am referring to the modules. What I meant was if we have 25 modules and everyone has its own license and notices file I'm pretty confident they'll get out of sync. It would be nice to have a central place to pull the content from which should be modules/scripts/resources/* What I meant by the notices being an issue is that a single notices file identifies what additional licenses are in a module. So, it may or may not make sense for the Kernel module to have a Bouncycastle NOTICE. If its ok to havbe a complete NOTICES file that includes licenses that are not in a module then that would be fine. It would be nice to say, Geronimo-Kernel may include one or more of the following elements. If we have to be precise on a module by module basis then I think that will be a problem. Kevan Miller wrote: On Jul 17, 2006, at 1:06 PM, Matt Hogstrom wrote: Well, I think adding the files to every module is potentially a problem. I think the release should have a central place all modules derive their LICENSE file from. The NOTICIES file is a different animal. Matt, What modules are you referring to? All of our generated jar files (.e.g geronimo-kernel-1.1.jar) should contain LICENSE and NOTICE files. Hrrm, I just looked at two 1.1 jars and they only contain LICENSE files. We also need a LICENSE and NOTICE file at the base of our distributions. These should contain all necessary license and notice information for all of the Geronimo code built and included in our distribution. The license and notice file also need to contain license and notice information for all jar files, or other artifacts, that we include in our distribution (e.g. asm jar, castor jar, etc...). Or, are you instead referring to modules as in CAR's? If so, then they are a different animal. However, I don't think we're released from any licensing requirements. Given the guidelines in http://www.apache.org/dev/release.html#what-must-every-release-contain (see the Can I distribute a raw artifact? section at the bottom), I think that any downloadable artifact (distribution, car, jar, war, ear, etc) that we release to ibiblio should have appropriate license and notice files (alternatively, we stop releasing the artifact). --kevan Jason Dillon wrote: If we want to keep these guys in the jars, then we should move them to their standard src/main/resources/META-INF/* locations so that they get picked up automatically. --jason On Jul 16, 2006, at 5:27 PM, John Sisson wrote: Jason Dillon wrote: Um... when were these ever included in the module's jars before? --jason On Jul 16, 2006, at 5:04 PM, John Sisson wrote: Jason Dillon wrote: Does each module really need LICENSE.txt and NOTICE.txt? Or can we just have this at the top-level of the project? I'd rather have less duplicate files to maintain... Any comments? --jason I think they are needed as each downloadable jar (which each module has) should contain the license and notice files. Same with source archives, which AFAIK maven can produce for each individual module for use by IDE debuggers etc. John I just checked and if you look at geronimo-activation-1.1.jar it should contain META-INF\LICENSE.TXT . It is a problem that the NOTICE.txt file isn't also included. We should add a JIRA for the 1.1.1 release for that. John
Creating a secure connection system and using JMSXUserID support
Hi, I'm trying to modify ActiveMQ so it can handle SSL connections and authorize access to different queues based on client IDs. I've been looking at your JMSXUserID support ( http://incubator.apache.org/activemq/jmsxuserid.html) to see if it could be used for authentication once the connection has been established. From what I see, using the BrokerService.setPopulateJMSXUserID(true); causes the BrokerService to use a UserIDBroker, which in turn uses the ConnectionContext to retreive the userID. The problem I see is that the connection context is set in AbstractConnection.processMessage, which uses the producerId received from the message, which has been send by the producer (and is not validated by the server). This, to me, means that if the producer manages to guess a correct producerId, it will have impersonated another producer. Is this true? Thanks in advance, Sepand
[jira] Updated: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Prasad Kashyap updated GERONIMO-2067: - Attachment: console-configs.patch Here's a patch that will include the console configs into the build and build them successfully. Thx to Anita who did the initial legwork. Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 1.2 Attachments: applications.patch, applications.patch, configs.log, configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, console-configs.patch, etc.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- 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-2188) Need to configure CommitBeforeAutoCommit=true for Database Commits in Oracle
[ http://issues.apache.org/jira/browse/GERONIMO-2188?page=comments#action_12421704 ] Lin Sun commented on GERONIMO-2188: --- Re Jenck's email: Yes with the generic tranql wrapper, setting the commitBeforeAutocommit to true would force the commit happen right away. However this commitBeforeAutocommit isn't available for tranql XA oracle wrapper. For Oracle wrapper's LocalMCF, I can just change: super(new OracleDataSource(), new OracleExceptionSorter(), false); to super(new OracleDataSource(), new OracleExceptionSorter(), true); However, for Oracle wrapper's XAMCF class, the parent class AbstractXADataSourceMCF's contructor only takes the first 2 parms. Here are two options I can think of: 1st option: add the boolean commitBeforeAutocommit parm into the AbstractXADataSourceMCF's contructor, which will also require changes to the localTransactionCommit method in ManagedXAConnection. Also all the other vendor wrappers (db2, derby, mysql) will have to be updated. 2nd option: create the OracleManagedXAConnection class that extends AbstractManagedConnection. I would vote for 1st option as we have a quite big number of buggy database vendors. What do you think? 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: LDAP Authorization
Thanks! The patch is not coomplete yet. I still need help with integration into AMQ (Spring style properties) to be able to use it. (copied from previous post) I am not familiar with Spring and I was not able to deduce how to specify module properties in AMQ XML config file. I need help with this and I would very much appreciate the following: - given the LDAPAuthorizationMap.properties file produce XML file - given the LDAPAuthorizationMap.java add code changes to accept properties from XML file above Is there any documentation on this that I can read? Thanks and regards, NGC James.Strachan wrote: On 7/17/06, James Strachan [EMAIL PROTECTED] wrote: On 7/17/06, ngcutura [EMAIL PROTECTED] wrote: I saw an entry in JIRA AMQ-376. Would this be appropriate or another one is required? Can I create entry in JIRA as unprivileged user? I didn't try, to be honest, I thought that someone from the development team is authorized to manage entries in JIRA. :-)Anyone who registers with JIRA can create new JIRA issues. Anyone can create JIRA issues... http://incubator.apache.org/activemq/support.html Though we need to assign karma to you if someone wants to assign an issue to themselves http://incubator.apache.org/activemq/contributing.html I've created a JIRA for you so we can track the patch's progress etc. http://issues.apache.org/activemq/browse/AMQ-826 -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5367147 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Virtual Topics (was Re: Failover topic subscribers)
I added logging to AbstractRegion and the virtual topics broker to see what destinations are created when a consumer connects. INFO ConsumerGroupsBroker - Adding Consumer for Destination: topic://ActiveMQ.Advisory.TempQueue,topic://ActiveMQ.Advisory.TempTopic INFO AbstractRegion - Adding consumer: ID:photon.duncllc.com-60318-1153164652757-1:0:-1:1 When I add a consumer, I'm not sure why it's destination is a temp advisory topic. I expect to see the destination that the consumer is listening on: property name=destination value=ActiveMQ.Virtual.TESTGROUP1.TEST/ ??? I just noticed that the last 3 replies were to myself, so you were probably not notified. -- View this message in context: http://www.nabble.com/Re%3A-Virtual-Topics-%28was-Re%3A-Failover-topic-subscribers%29-tf1942508.html#a5367679 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Commented: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=comments#action_12421714 ] Jason Dillon commented on GERONIMO-2067: console patch applied (#422836) jetty j2ee now has a functional console :-) Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 1.2 Attachments: applications.patch, applications.patch, configs.log, configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, console-configs.patch, etc.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- 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
OpenEJB JIRAs for 1.1.1 - bugs or features ?
I opened 3 JIRAs that affect CMP deployment, Session bean performance and consistency. The JIRA's in question are: GERONIMO-2127 - Expose ability to use SELECT FOR UPDATE GERONIMO-2129 - Allow user to specify pool size on Stateless Session Beans GERONIMO-2128 - Allow user to specify an Isolation Level on a CMP Bean I think these items can be argued in two ways. Bugs and features. Based on my experience with CMP beans what we have for Geronimo is fully compliant with the J2EE specification. We pass the tests and are compliant. However, our current implementation does not allow for a user to deploy an application that will ensure data consistency. For instance, if one is using Oracle as the database, which operates at Read Committed by default, two competing applications will possible overlay data from one another with no notification at all. In order to properly provide for ACID properties a SELECT FOR UPDATE needs to be provided so one application can block another. I consider this a bug since even though the implementation is compliant it is also unusable unless your data is read-only or you can guarantee no conflicts in some other way. The second issue goes to consumability as well as accuracy. Stateless session beans are traditionally used as facades and wrappers for Tx. They are also used to store information that is transient but expected to be longer lived than a single use. The SLSB in OpenEJB has a pool size of one and will make some applications perform poorly and perhaps malfunction. In the case of SPECjAppServer it will do both. The SLSB is used in that application as a temporary cache for keys used to insert into a database. The current behaviour is that on every request a new block of keys is retrieved from the Key database. For SPECj and DayTrader it results in deadlocks and collided keys. The Pool (which does exist but is fixed at a size of 1) will eliminate this problem. 2128 is similar to 2127 in so far as using database isolation to provide ACID properties it allows for multiple Isolation levels to be used such that RDBMs such as DB2 or Derby can perform better. Although this isn't required for ACID properties it does require a schema change to OEJB 2.1.1. All of these JIRA's can be implemented without disrupting current applications so I believe we should include them in 1.1.1. The changes are actually limited to OEJB and TranQL which are components of G. My vote is to include these JIRA's. Matt
Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
+1 include them On 7/17/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I opened 3 JIRAs that affect CMP deployment, Session bean performance and consistency. The JIRA's in question are: GERONIMO-2127 - Expose ability to use SELECT FOR UPDATE GERONIMO-2129 - Allow user to specify pool size on Stateless Session Beans GERONIMO-2128 - Allow user to specify an Isolation Level on a CMP Bean I think these items can be argued in two ways. Bugs and features. Based on my experience with CMP beans what we have for Geronimo is fully compliant with the J2EE specification. We pass the tests and are compliant. However, our current implementation does not allow for a user to deploy an application that will ensure data consistency. For instance, if one is using Oracle as the database, which operates at Read Committed by default, two competing applications will possible overlay data from one another with no notification at all. In order to properly provide for ACID properties a SELECT FOR UPDATE needs to be provided so one application can block another. I consider this a bug since even though the implementation is compliant it is also unusable unless your data is read-only or you can guarantee no conflicts in some other way. The second issue goes to consumability as well as accuracy. Stateless session beans are traditionally used as facades and wrappers for Tx. They are also used to store information that is transient but expected to be longer lived than a single use. The SLSB in OpenEJB has a pool size of one and will make some applications perform poorly and perhaps malfunction. In the case of SPECjAppServer it will do both. The SLSB is used in that application as a temporary cache for keys used to insert into a database. The current behaviour is that on every request a new block of keys is retrieved from the Key database. For SPECj and DayTrader it results in deadlocks and collided keys. The Pool (which does exist but is fixed at a size of 1) will eliminate this problem. 2128 is similar to 2127 in so far as using database isolation to provide ACID properties it allows for multiple Isolation levels to be used such that RDBMs such as DB2 or Derby can perform better. Although this isn't required for ACID properties it does require a schema change to OEJB 2.1.1. All of these JIRA's can be implemented without disrupting current applications so I believe we should include them in 1.1.1. The changes are actually limited to OEJB and TranQL which are components of G. My vote is to include these JIRA's. Matt
Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
I think the first two are definitely bugs. You lost me on the discussion of 2128... I'd like to see the discussion included on OpenEJB dev, also... --kevan On Jul 17, 2006, at 4:47 PM, Matt Hogstrom wrote: I opened 3 JIRAs that affect CMP deployment, Session bean performance and consistency. The JIRA's in question are: GERONIMO-2127 - Expose ability to use SELECT FOR UPDATE GERONIMO-2129 - Allow user to specify pool size on Stateless Session Beans GERONIMO-2128 - Allow user to specify an Isolation Level on a CMP Bean I think these items can be argued in two ways. Bugs and features. Based on my experience with CMP beans what we have for Geronimo is fully compliant with the J2EE specification. We pass the tests and are compliant. However, our current implementation does not allow for a user to deploy an application that will ensure data consistency. For instance, if one is using Oracle as the database, which operates at Read Committed by default, two competing applications will possible overlay data from one another with no notification at all. In order to properly provide for ACID properties a SELECT FOR UPDATE needs to be provided so one application can block another. I consider this a bug since even though the implementation is compliant it is also unusable unless your data is read-only or you can guarantee no conflicts in some other way. The second issue goes to consumability as well as accuracy. Stateless session beans are traditionally used as facades and wrappers for Tx. They are also used to store information that is transient but expected to be longer lived than a single use. The SLSB in OpenEJB has a pool size of one and will make some applications perform poorly and perhaps malfunction. In the case of SPECjAppServer it will do both. The SLSB is used in that application as a temporary cache for keys used to insert into a database. The current behaviour is that on every request a new block of keys is retrieved from the Key database. For SPECj and DayTrader it results in deadlocks and collided keys. The Pool (which does exist but is fixed at a size of 1) will eliminate this problem. 2128 is similar to 2127 in so far as using database isolation to provide ACID properties it allows for multiple Isolation levels to be used such that RDBMs such as DB2 or Derby can perform better. Although this isn't required for ACID properties it does require a schema change to OEJB 2.1.1. All of these JIRA's can be implemented without disrupting current applications so I believe we should include them in 1.1.1. The changes are actually limited to OEJB and TranQL which are components of G. My vote is to include these JIRA's. Matt
Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
Matt Hogstrom wrote: I opened 3 JIRAs that affect CMP deployment, Session bean performance and consistency. The JIRA's in question are: GERONIMO-2127 - Expose ability to use SELECT FOR UPDATE GERONIMO-2129 - Allow user to specify pool size on Stateless Session Beans GERONIMO-2128 - Allow user to specify an Isolation Level on a CMP Bean I think these items can be argued in two ways. Bugs and features. Based on my experience with CMP beans what we have for Geronimo is fully compliant with the J2EE specification. We pass the tests and are compliant. However, our current implementation does not allow for a user to deploy an application that will ensure data consistency. For instance, if one is using Oracle as the database, which operates at Read Committed by default, two competing applications will possible overlay data from one another with no notification at all. In order to properly provide for ACID properties a SELECT FOR UPDATE needs to be provided so one application can block another. I consider this a bug since even though the implementation is compliant it is also unusable unless your data is read-only or you can guarantee no conflicts in some other way. The second issue goes to consumability as well as accuracy. Stateless session beans are traditionally used as facades and wrappers for Tx. They are also used to store information that is transient but expected to be longer lived than a single use. The SLSB in OpenEJB has a pool size of one and will make some applications perform poorly and perhaps malfunction. In the case of SPECjAppServer it will do both. The SLSB is used in that application as a temporary cache for keys used to insert into a database. The current behaviour is that on every request a new block of keys is retrieved from the Key database. For SPECj and DayTrader it results in deadlocks and collided keys. The Pool (which does exist but is fixed at a size of 1) will eliminate this problem. 2128 is similar to 2127 in so far as using database isolation to provide ACID properties it allows for multiple Isolation levels to be used such that RDBMs such as DB2 or Derby can perform better. Although this isn't required for ACID properties it does require a schema change to OEJB 2.1.1. All of these JIRA's can be implemented without disrupting current applications so I believe we should include them in 1.1.1. The changes are actually limited to OEJB and TranQL which are components of G. My vote is to include these JIRA's. Include them if you can get them done in time. Regards, Alan
Re: svn commit: r422640 - /geronimo/configs/
Hey Jason, These paths were used by the Continuum builds on GBuild. For example the Geronimo 1.2 :: Configs build used geronimo/configs. So, at the moment the configs, applications, and assembly phases of the G 1.2 build are broken. I've never really cared for separating the build steps on Continuum (eg, modules, applications, configs, and assembly). I don't think separating them gives us much, if any benefit, and may actually cause some confusion... AFAIK, there's nothing that insures subsequent build phases (e.g. assembly) runs after a modules build. Also, I don't think there's anything to insure proper build order -- I'd hacked the current projects to build in the proper order by renaming the assembly project to Z Assembly. I'd just as soon always run a full build even if only a config plan has changed. So, unless I hear any objections. I'm going to delete the existing Continuum Geronimo 1.2 projects and have just one Geronimo 1.2 project that runs a full Geronimo build. --kevan On Jul 17, 2006, at 2:45 AM, [EMAIL PROTECTED] wrote: Author: jdillon Date: Sun Jul 16 23:45:15 2006 New Revision: 422640 URL: http://svn.apache.org/viewvc?rev=422640view=rev Log: Drop this unused path Removed: geronimo/configs/
Jencks and Lingo projects on Continuum
Somebody recently added Jencks and Lingo projects to Continuum running on GGbuild. That's all fine. However, the builds are failing. I tried fixing up the svn url being used for the Jencks project, but it's still failing. Could whoever added the projects fix things up so that the builds work? Otherwise, I'm going to delete them one week from today (July 24). If you have questions or problems, I'm happy to help (although I'm far from an expert...). --kevan
Re: svn commit: r422640 - /geronimo/configs/
I agree.Is there a way to import a project into Continuum and only have a single project created using the root pom that does a full build, rather then one for every pom?On Jul 17, 2006, at 5:53 PM, Kevan Miller wrote:Hey Jason,These paths were used by the Continuum builds on GBuild. For example the "Geronimo 1.2 :: Configs" build used geronimo/configs. So, at the moment the configs, applications, and assembly phases of the G 1.2 build are broken.I've never really cared for separating the build steps on Continuum (eg, modules, applications, configs, and assembly). I don't think separating them gives us much, if any benefit, and may actually cause some confusion... AFAIK, there's nothing that insures subsequent build phases (e.g. assembly) runs after a modules build. Also, I don't think there's anything to insure proper build order -- I'd hacked the current projects to build in the proper order by renaming the assembly project to "Z Assembly". I'd just as soon always run a full build even if only a config plan has changed.So, unless I hear any objections. I'm going to delete the existing Continuum Geronimo 1.2 projects and have just one Geronimo 1.2 project that runs a full Geronimo build.--kevanOn Jul 17, 2006, at 2:45 AM, [EMAIL PROTECTED] wrote: Author: jdillonDate: Sun Jul 16 23:45:15 2006New Revision: 422640URL: http://svn.apache.org/viewvc?rev=422640view=revLog:Drop this unused pathRemoved: geronimo/configs/ -sachin
Re: svn commit: r422640 - /geronimo/configs/
On Jul 17, 2006, at 6:12 PM, Sachin Patel wrote:I agree.Is there a way to import a project into Continuum and only have a single project created using the root pom that does a full build, rather then one for every pom?Well, you can always add as a "shell" project, rather than as maven 1 or 2 project. That's how a fair number of our existing projects were added.--kevan On Jul 17, 2006, at 5:53 PM, Kevan Miller wrote:Hey Jason,These paths were used by the Continuum builds on GBuild. For example the "Geronimo 1.2 :: Configs" build used geronimo/configs. So, at the moment the configs, applications, and assembly phases of the G 1.2 build are broken.I've never really cared for separating the build steps on Continuum (eg, modules, applications, configs, and assembly). I don't think separating them gives us much, if any benefit, and may actually cause some confusion... AFAIK, there's nothing that insures subsequent build phases (e.g. assembly) runs after a modules build. Also, I don't think there's anything to insure proper build order -- I'd hacked the current projects to build in the proper order by renaming the assembly project to "Z Assembly". I'd just as soon always run a full build even if only a config plan has changed.So, unless I hear any objections. I'm going to delete the existing Continuum Geronimo 1.2 projects and have just one Geronimo 1.2 project that runs a full Geronimo build.--kevanOn Jul 17, 2006, at 2:45 AM, [EMAIL PROTECTED] wrote: Author: jdillonDate: Sun Jul 16 23:45:15 2006New Revision: 422640URL: http://svn.apache.org/viewvc?rev=422640view=revLog:Drop this unused pathRemoved: geronimo/configs/ -sachin
Remove GeronimoExecutor?
Can we remove the interface GeronimoExecutor from Geronimo or at the
very least have no services use it? For those of you whom are not
aware of this interface, it adds a getName and getObjectName
interface to an Executor. Here is the code:
public interface GeronimoExecutor extends Executor,
org.apache.geronimo.system.threads.ThreadPool {
/**
* Gets a human-readable name identifying this object.
*/
String getName();
/**
* Gets the unique name of this object. The object name must
comply with
* the ObjectName specification in the JMX specification.
*
* @return the unique name of this object within the server
*/
String getObjectName();
}
I searched the code base and there isn't a single use of the getName
and getObjectName methods. The problem is the Work manager needs one
of these in the constructor, but it only uses the execute method
declared on in the Executor and ThreadPool interfaces. This means
that if you want to use the work manager you must take both the
geronimo-core and geronimo-system jars to get the GeronimoExecutor
and ThreadPool interfaces respectively.
So can we please please please remove this interface and just use
Executor?
I'd like to do this in both 1.2 and 1.1.1.
-dain
Re: Remove GeronimoExecutor?
There's a method somewhere (perhaps ThreadPool) that takes a name and
a runnable and is useful in that the console can then show what kind
of work is being done with the thread pool -- particularly useful for
things like the default thread pool which can be used all over the
place. I don't really fancy removing that. But I'm fine with
removing the interface below.
Thanks,
Aaron
On 7/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
Can we remove the interface GeronimoExecutor from Geronimo or at the
very least have no services use it? For those of you whom are not
aware of this interface, it adds a getName and getObjectName
interface to an Executor. Here is the code:
public interface GeronimoExecutor extends Executor,
org.apache.geronimo.system.threads.ThreadPool {
/**
* Gets a human-readable name identifying this object.
*/
String getName();
/**
* Gets the unique name of this object. The object name must
comply with
* the ObjectName specification in the JMX specification.
*
* @return the unique name of this object within the server
*/
String getObjectName();
}
I searched the code base and there isn't a single use of the getName
and getObjectName methods. The problem is the Work manager needs one
of these in the constructor, but it only uses the execute method
declared on in the Executor and ThreadPool interfaces. This means
that if you want to use the work manager you must take both the
geronimo-core and geronimo-system jars to get the GeronimoExecutor
and ThreadPool interfaces respectively.
So can we please please please remove this interface and just use
Executor?
I'd like to do this in both 1.2 and 1.1.1.
-dain
Re: Remove GeronimoExecutor?
How about we just implement toString() on our Runnables, and our
thread pool can track that way? I really want to uncouple this code.
-dain
On Jul 17, 2006, at 4:58 PM, Aaron Mulder wrote:
There's a method somewhere (perhaps ThreadPool) that takes a name and
a runnable and is useful in that the console can then show what kind
of work is being done with the thread pool -- particularly useful for
things like the default thread pool which can be used all over the
place. I don't really fancy removing that. But I'm fine with
removing the interface below.
Thanks,
Aaron
On 7/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
Can we remove the interface GeronimoExecutor from Geronimo or at the
very least have no services use it? For those of you whom are not
aware of this interface, it adds a getName and getObjectName
interface to an Executor. Here is the code:
public interface GeronimoExecutor extends Executor,
org.apache.geronimo.system.threads.ThreadPool {
/**
* Gets a human-readable name identifying this object.
*/
String getName();
/**
* Gets the unique name of this object. The object name must
comply with
* the ObjectName specification in the JMX specification.
*
* @return the unique name of this object within the server
*/
String getObjectName();
}
I searched the code base and there isn't a single use of the getName
and getObjectName methods. The problem is the Work manager needs one
of these in the constructor, but it only uses the execute method
declared on in the Executor and ThreadPool interfaces. This means
that if you want to use the work manager you must take both the
geronimo-core and geronimo-system jars to get the GeronimoExecutor
and ThreadPool interfaces respectively.
So can we please please please remove this interface and just use
Executor?
I'd like to do this in both 1.2 and 1.1.1.
-dain
Re: svn commit: r422640 - /geronimo/configs/
What was the purpose of the property file that was contained there? Sorry... I will get all of the CI bits cleaned up soon... --jason On Jul 17, 2006, at 2:53 PM, Kevan Miller wrote: Hey Jason, These paths were used by the Continuum builds on GBuild. For example the Geronimo 1.2 :: Configs build used geronimo/configs. So, at the moment the configs, applications, and assembly phases of the G 1.2 build are broken. I've never really cared for separating the build steps on Continuum (eg, modules, applications, configs, and assembly). I don't think separating them gives us much, if any benefit, and may actually cause some confusion... AFAIK, there's nothing that insures subsequent build phases (e.g. assembly) runs after a modules build. Also, I don't think there's anything to insure proper build order -- I'd hacked the current projects to build in the proper order by renaming the assembly project to Z Assembly. I'd just as soon always run a full build even if only a config plan has changed. So, unless I hear any objections. I'm going to delete the existing Continuum Geronimo 1.2 projects and have just one Geronimo 1.2 project that runs a full Geronimo build. --kevan On Jul 17, 2006, at 2:45 AM, [EMAIL PROTECTED] wrote: Author: jdillon Date: Sun Jul 16 23:45:15 2006 New Revision: 422640 URL: http://svn.apache.org/viewvc?rev=422640view=rev Log: Drop this unused path Removed: geronimo/configs/
Re: [DISCUSSION] Content for 1.2
On Jul 14, 2006, at 9:48 PM, Matt Hogstrom wrote: 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. All my ideas below depend on RTC working somewhat more than it has so far, or my finding a way to develop these features outside geronimo. The pluggable jacc patch has been in RTC since July 3 with 1 +1 and no other comments. djencks pluggable jacc, at least the framework if not another jacc implementation plugged in (might be done depending on results of RTC) djencks global jndi, either working with Krishnakumar B (GERONIMO-21530) or independently djencks make jpa available to jee applications (I don't understand the problems well enough yet to say more) djencks jetspeed 2 integration thanks david jencks Let the games begin...
[jira] Updated: (GERONIMO-2120) Can't have ejb references outside current config. ClassCastException on org.openejb.proxy.ProxyInfo
[ http://issues.apache.org/jira/browse/GERONIMO-2120?page=all ] David Jencks updated GERONIMO-2120: --- Fix Version/s: 1.1.1 Assignee: David Jencks Priority: Blocker (was: Major) I believe quite a few users have run into this problem. Can't have ejb references outside current config. ClassCastException on org.openejb.proxy.ProxyInfo Key: GERONIMO-2120 URL: http://issues.apache.org/jira/browse/GERONIMO-2120 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, OpenEJB Affects Versions: 1.1 Environment: Win XP, Intel, Sun JDK 142 Reporter: Ted Kirby Assigned To: David Jencks Priority: Blocker Fix For: 1.1.1 Attachments: GERONIMO-2120-djencks.patch See http://mail-archives.apache.org/mod_mbox/geronimo-user/200606.mbox/[EMAIL PROTECTED] I deploy (or distribute) a jar with an ejb, then deploy (or distribute) a war that references the ejb, and get: Error: Operation failed: java.lang.ClassCastException with this server.log entry: 10:51:39,531 ERROR [Deployer] Deployment failed due to java.lang.ClassCastException at org.openejb.deployment.OpenEJBReferenceBuilder.checkRemoteProxyInfo(OpenEJBReferenceBuilder.java:133) at org.openejb.deployment.OpenEJBReferenceBuilder.createEJBRemoteRef(OpenEJBReferenceBuilder.java:159) at org.openejb.deployment.OpenEJBReferenceBuilder$$FastClassByCGLIB$$bfd62c9f.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.EJBReferenceBuilder$$EnhancerByCGLIB$$d6cd2b5d.createEJBRemoteRef(generated) at org.apache.geronimo.j2ee.deployment.RefContext.getEJBRemoteRef(RefContext.java:69) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.addEJBRef(ENCConfigBuilder.java:412) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.addEJBRefs(ENCConfigBuilder.java:339) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponentContext(ENCConfigBuilder.java:731) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.buildComponentContext(TomcatModuleBuilder.java:458) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:288) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder$$FastClassByCGLIB$$6f85ec2c.invoke(generated) -- 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-2142) EJB Refs to EJB in parent module often fail
[ http://issues.apache.org/jira/browse/GERONIMO-2142?page=all ] David Jencks updated GERONIMO-2142: --- Fix Version/s: 1.1.1 (was: 1.1.x) Assignee: David Jencks I'll see if I can figure out what's going on here and fix it. EJB Refs to EJB in parent module often fail --- Key: GERONIMO-2142 URL: http://issues.apache.org/jira/browse/GERONIMO-2142 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, OpenEJB Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: David Jencks Fix For: 1.1.1 In OpenEJBReferenceBuilder: createEJBLocalRef and createEJBRemoteRef accept a targetConfigId argument. Then they often call getMatch or getImplicitMatch and don't use the targetConfigId. As a result, the current module's ID is always used as the targetConfigId: context.findGBeans(new AbstractNameQuery(context.getId(), ... This means that the query will never match EJBs in a parent of the current configuration. It should be changed to use the targetConfigId instead of the current module's ID. This does not come up if a pattern element is used in the mapping, though that mapping strategy runs into a different 1.1 bug (ClassCastException on org.openejb.proxy.ProxyInfo) -- 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: (DAYTRADER-6) Longer version (1.1.1) causes build failures on Windows in daytrader-jetty config
[ http://issues.apache.org/jira/browse/DAYTRADER-6?page=comments#action_12421758 ] John Sisson commented on DAYTRADER-6: - I found that if I renamed the project.xml files in the following projects so they are ignored the build succeeded. 1.1\applications\daytrader 1.1\configs\daytrader-jetty 1.1\configs\daytrader-tomcat I seem to remember there was some mention of moving these projects out of the Geronimo build. Is there a JIRA for this so we don't forget. Not sure when this move was planned. I can workaround the issue, so it isn't high priority. Longer version (1.1.1) causes build failures on Windows in daytrader-jetty config - Key: DAYTRADER-6 URL: http://issues.apache.org/jira/browse/DAYTRADER-6 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 1.1.1 Reporter: John Sisson Whilst developing Geronimo 1.1 for the 1.1 release I was able to build ok from a windows path C:\dev\geronimo\br\1.1 . Now that the versions have been bumped up to 1.1.1 I am now getting build failures due to the max windows file path being exceeded. An example of a path that has a problem is the following (which is 261 bytes long) C:\dev\geronimo\br\1.1\configs\daytrader-jetty\target\repository\geronimo\daytrader-derby-jetty\1.1.1-SNAPSHOT\daytrader-derby-jetty-1.1.1-SNAPSHOT.car\web.war\WEB-INF\classes\org\apache\geronimo\samples\daytrader\web\prims\PingServlet2Session2CMROne2Many.class It looks like we need to do some further trimming of file names (e.g. like in the patch attached to GERONIMO-1790). The following is the build output: + | configurations Daytrader using derby deployed on jetty | Memory: 55M/69M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download geronimo-daytrader-derby-db-1.1.1-SNAPSHOT.jar. Artifact /geronimo/jars/geronimo-daytrader-derby-db-1.1.1-SNAPSHOT.jar doesn't exist in remote repository, but it exists locally. Attempting to download daytrader-ear-1.1.ear. 983K downloaded Attempting to download openejb-1.1.1-SNAPSHOT.car. Artifact /geronimo/cars/openejb-1.1.1-SNAPSHOT.car doesn't exist in remote repository, but it exists locally. build:start: multiproject:install-callback: [echo] Running car:install for Daytrader using derby deployed on jetty car:prepare-plan: car:package: [delete] Deleting directory C:\dev\geronimo\br\1.1\configs\daytrader-jetty\target\repository [mkdir] Created dir: C:\dev\geronimo\br\1.1\configs\daytrader-jetty\target\repository Packaging configuration C:\dev\geronimo\br\1.1\configs\daytrader-jetty\target\plan\plan.xml Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. 16:51:12,169 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 16:51:12,607 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geroni mo.apache.org 16:51:12,654 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 16:51:12,669 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 16:51:12,669 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geroni mo.apache.org 16:51:12,685 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 16:51:12,685 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.g eronimo.apache.org 16:51:12,701 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.g eronimo.apache.org 16:51:12,701 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples .geronimo.apache.org 16:51:13,076 ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: Could not load servlet class org.apache.geronimo .samples.daytrader.web.prims.PingServlet2Session2CMROne2Many org.apache.geronimo.common.DeploymentException: Could not load servlet class org.apache.geronimo.samples.daytrader.web.prims.PingSer vlet2Session2CMROne2Many at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addServlet(JettyModuleBuilder.java:837)
[jira] Updated: (DAYTRADER-6) Longer version (1.1.1) causes build failures on Windows in daytrader-jetty config
[ http://issues.apache.org/jira/browse/DAYTRADER-6?page=all ] John Sisson updated DAYTRADER-6: Fix Version/s: (was: 1.1.1) Longer version (1.1.1) causes build failures on Windows in daytrader-jetty config - Key: DAYTRADER-6 URL: http://issues.apache.org/jira/browse/DAYTRADER-6 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 1.1.1 Reporter: John Sisson Whilst developing Geronimo 1.1 for the 1.1 release I was able to build ok from a windows path C:\dev\geronimo\br\1.1 . Now that the versions have been bumped up to 1.1.1 I am now getting build failures due to the max windows file path being exceeded. An example of a path that has a problem is the following (which is 261 bytes long) C:\dev\geronimo\br\1.1\configs\daytrader-jetty\target\repository\geronimo\daytrader-derby-jetty\1.1.1-SNAPSHOT\daytrader-derby-jetty-1.1.1-SNAPSHOT.car\web.war\WEB-INF\classes\org\apache\geronimo\samples\daytrader\web\prims\PingServlet2Session2CMROne2Many.class It looks like we need to do some further trimming of file names (e.g. like in the patch attached to GERONIMO-1790). The following is the build output: + | configurations Daytrader using derby deployed on jetty | Memory: 55M/69M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: Attempting to download geronimo-daytrader-derby-db-1.1.1-SNAPSHOT.jar. Artifact /geronimo/jars/geronimo-daytrader-derby-db-1.1.1-SNAPSHOT.jar doesn't exist in remote repository, but it exists locally. Attempting to download daytrader-ear-1.1.ear. 983K downloaded Attempting to download openejb-1.1.1-SNAPSHOT.car. Artifact /geronimo/cars/openejb-1.1.1-SNAPSHOT.car doesn't exist in remote repository, but it exists locally. build:start: multiproject:install-callback: [echo] Running car:install for Daytrader using derby deployed on jetty car:prepare-plan: car:package: [delete] Deleting directory C:\dev\geronimo\br\1.1\configs\daytrader-jetty\target\repository [mkdir] Created dir: C:\dev\geronimo\br\1.1\configs\daytrader-jetty\target\repository Packaging configuration C:\dev\geronimo\br\1.1\configs\daytrader-jetty\target\plan\plan.xml Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'. 16:51:12,169 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 16:51:12,607 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geroni mo.apache.org 16:51:12,654 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 16:51:12,669 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 16:51:12,669 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geroni mo.apache.org 16:51:12,685 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.geronimo .apache.org 16:51:12,685 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.g eronimo.apache.org 16:51:12,701 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples.g eronimo.apache.org 16:51:12,701 WARN [HeavyweightTypeInfoBuilder] No soap array info for schematype: [EMAIL PROTECTED]://daytrader.samples .geronimo.apache.org 16:51:13,076 ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: Could not load servlet class org.apache.geronimo .samples.daytrader.web.prims.PingServlet2Session2CMROne2Many org.apache.geronimo.common.DeploymentException: Could not load servlet class org.apache.geronimo.samples.daytrader.web.prims.PingSer vlet2Session2CMROne2Many at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addServlet(JettyModuleBuilder.java:837) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addServlets(JettyModuleBuilder.java:797) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:704) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder$$FastClassByCGLIB$$b30bba8a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at
Re: Re: Remove GeronimoExecutor?
On 7/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
How about we just implement toString() on our Runnables, and our
thread pool can track that way? I really want to uncouple this code.
The problem is that if you forget that, or use one bit of code outside
our control (e.g. Tomcat, Jetty, etc.) you instantly get really nasty
entries on the screen that shows the statistics. At least now we can
tell which ones aren't implemented and just bundle those into an
unknown category. I'm open to alternatives, but I don't like the
toString one so much.
In any case, you can definitely remove GeronimoExecutor.
Thanks,
Aaron
On Jul 17, 2006, at 4:58 PM, Aaron Mulder wrote:
There's a method somewhere (perhaps ThreadPool) that takes a name and
a runnable and is useful in that the console can then show what kind
of work is being done with the thread pool -- particularly useful for
things like the default thread pool which can be used all over the
place. I don't really fancy removing that. But I'm fine with
removing the interface below.
Thanks,
Aaron
On 7/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
Can we remove the interface GeronimoExecutor from Geronimo or at the
very least have no services use it? For those of you whom are not
aware of this interface, it adds a getName and getObjectName
interface to an Executor. Here is the code:
public interface GeronimoExecutor extends Executor,
org.apache.geronimo.system.threads.ThreadPool {
/**
* Gets a human-readable name identifying this object.
*/
String getName();
/**
* Gets the unique name of this object. The object name must
comply with
* the ObjectName specification in the JMX specification.
*
* @return the unique name of this object within the server
*/
String getObjectName();
}
I searched the code base and there isn't a single use of the getName
and getObjectName methods. The problem is the Work manager needs one
of these in the constructor, but it only uses the execute method
declared on in the Executor and ThreadPool interfaces. This means
that if you want to use the work manager you must take both the
geronimo-core and geronimo-system jars to get the GeronimoExecutor
and ThreadPool interfaces respectively.
So can we please please please remove this interface and just use
Executor?
I'd like to do this in both 1.2 and 1.1.1.
-dain
[jira] Commented: (GERONIMO-2167) deployer.jar not cleaning up properly during redeploy and undeploy
[
http://issues.apache.org/jira/browse/GERONIMO-2167?page=comments#action_12421765
]
Leonard Wu commented on GERONIMO-2167:
--
Thanks for the diagnosis.
You were quite right. Closing the resources released the lock and solved the
problem. Just the InputStreamReader and BufferedReader were enough, didn't have
to close any HSQL connection.
And I agree, G should handle such rogue coding (thankfully not my own) more
gracefully.
deployer.jar not cleaning up properly during redeploy and undeploy
--
Key: GERONIMO-2167
URL: http://issues.apache.org/jira/browse/GERONIMO-2167
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 1.1
Environment: Win32/XP SP1
Sun JDK 1.5_06
Reporter: Leonard Wu
Assigned To: Kevan Miller
Fix For: 1.1.1
Attachments: dwr-demo.war, jw-0620-dwr.zip
deployment using deploy.jar doesn't appear to clean up correctly.
first deploy always works. subsequent re-deploy and un-deploy are problematic.
following illustrates the full sequence of events as i had encountered:
--
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager deploy D:/work/SERVER/dwr-demo.war
Deployed littleoldme/dwrdemo/1.1/war @ http://vaio:8080/dwr-demo
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Deployed littleoldme/dwrdemo/1.1/war
Started littleoldme/dwrdemo/1.1/war
Redeployed littleoldme/dwrdemo/1.1/war
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager redeploy D:/work/SERVER/dwr-demo.war
No ModuleID or TargetModuleID provided. Attempting to guess based
on the content of the archive.
Attempting to use ModuleID 'littleoldme/dwrdemo/1.1/war'
Stopped littleoldme/dwrdemo/1.1/war
Unloaded littleoldme/dwrdemo/1.1/war
Uninstalled littleoldme/dwrdemo/1.1/war
Error: Operation failed:
org.apache.geronimo.kernel.config.ConfigurationAlreadyExistsException:
Configuration already exists: littleoldme/dwrdemo/1.1/war
Configuration already exists: littleoldme/dwrdemo/1.1/war
D:\work\SERVER\geronimo-1.1\binc:\JDK\jdk1.5.0_06\bin\java.exe -jar
deployer.ja
r --user system --password manager undeploy littleoldme/dwrdemo/1.1/war
Error: littleoldme/dwrdemo/1.1/war does not appear to be a the name
of a module available on the selected server. Perhaps it has already
been stopped or undeployed? If you're trying to specify a
TargetModuleID, use the syntax TargetName|ModuleName instead. If
you're not sure what's running, try the list-modules command.
--
While in this broken state, i'm able to recover by manually removing the
${geronimo}/repository/littleoldme directory and removing the one line in
${geronimo}/var/config/config.xml that says
module load=false name=littleoldme/dwrdemo/1.1/war/
However, this only gets me to a fresh beginning, and then the whole sequence
starts again as I repeat (re/un)deploying.
--
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: Jencks and Lingo projects on Continuum
BTW it was me - I'm always on the look out of a CI server we can use on OSS projects :). I'll try get the builds working. Does it really affect Geronimo if the builds fail? AFAIK build error mail should be going to the Jencks Lingo projects? On 7/17/06, Kevan Miller [EMAIL PROTECTED] wrote: Somebody recently added Jencks and Lingo projects to Continuum running on GGbuild. That's all fine. However, the builds are failing. I tried fixing up the svn url being used for the Jencks project, but it's still failing. Could whoever added the projects fix things up so that the builds work? Otherwise, I'm going to delete them one week from today (July 24). If you have questions or problems, I'm happy to help (although I'm far from an expert...). --kevan -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (GERONIMO-2201) Configs migration: remote-deploy-*
Configs migration: remote-deploy-* -- Key: GERONIMO-2201 URL: http://issues.apache.org/jira/browse/GERONIMO-2201 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Prasad Kashyap Fix For: 1.2 Patch will include remote-deploy-* configs into the M2 build and jetty assembly. -- 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: Creating a secure connection system and using JMSXUserID support
On 7/17/06, Sepand M [EMAIL PROTECTED] wrote: Hi, I'm trying to modify ActiveMQ so it can handle SSL connections FWIW we already support SSL connections... http://incubator.apache.org/activemq/configuring-transports.html in particular... http://incubator.apache.org/activemq/ssl-transport-reference.html and authorize access to different queues based on client IDs. We have a security plugin to perform authentication and authorization on specific destinations, details here... http://incubator.apache.org/activemq/security.html I've been looking at your JMSXUserID support ( http://incubator.apache.org/activemq/jmsxuserid.html) to see if it could be used for authentication once the connection has been established. So the purpose of the JMSXUserID feature is to be able to add a header to all JMS messages that leave a broker so that consumers receiving the message can know the authenticated user ID who sent the message. i.e. it means that a producer cannot spoof its userID when sending a message. JMSXUserID does not perform the actual authentication/authorization - thats a feature of the security plugin I mentioned above. From what I see, using the BrokerService.setPopulateJMSXUserID(true); causes the BrokerService to use a UserIDBroker, which in turn uses the ConnectionContext to retreive the userID. The problem I see is that the connection context is set in AbstractConnection.processMessage, which uses the producerId received from the message, which has been send by the producer (and is not validated by the server). This, to me, means that if the producer manages to guess a correct producerId, it will have impersonated another producer. Is this true? The clientID is the thing we use; something the client can generate itself. Though we ensure that only 1 connection that is active has a single clientID value at any point in time (so no client can pretend to be another one - its also required by the JMS spec). So I don't think it matters too much what the producerId is - unless I've misunderstood your point -- James --- http://radio.weblogs.com/0112098/
Re: Virtual Topics (was Re: Failover topic subscribers)
Sorry I've not responded to this thread yet - been a bit snowed on other stuff. Yes I think we should be creating the destinations in addConsumer() BTW. The reason for the creation of the ActiveMQ.Advisory.TempQueue is I think part of the usual advisory mechanism... http://incubator.apache.org/activemq/advisory-message.html Incidentally in the example you give, was the consumer adding a consumer to a temporary queue? On 7/17/06, bmadigan [EMAIL PROTECTED] wrote: I added logging to AbstractRegion and the virtual topics broker to see what destinations are created when a consumer connects. INFO ConsumerGroupsBroker - Adding Consumer for Destination: topic://ActiveMQ.Advisory.TempQueue,topic://ActiveMQ.Advisory.TempTopic INFO AbstractRegion - Adding consumer: ID:photon.duncllc.com-60318-1153164652757-1:0:-1:1 When I add a consumer, I'm not sure why it's destination is a temp advisory topic. I expect to see the destination that the consumer is listening on: property name=destination value=ActiveMQ.Virtual.TESTGROUP1.TEST/ ??? I just noticed that the last 3 replies were to myself, so you were probably not notified. -- View this message in context: http://www.nabble.com/Re%3A-Virtual-Topics-%28was-Re%3A-Failover-topic-subscribers%29-tf1942508.html#a5367679 Sent from the ActiveMQ - Dev forum at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
Re: Creating a secure connection system and using JMSXUserID support
Thanks James, I'm mentoring Sepand on this project within our company, so I'll try to explain what we're trying to do. We want to use SSL client-side certificates to provide the authentication mechanism rather than user/pass or other authentication, so he is working to extend the SSL transport to do that. We already have an existing system using this for https web services style requests, and want to use the same mechanism with ActiveMQ. Does this seem like a reasonable extension? I haven't had time to study the part of the code he's asking about in depth, but it sounds like we are not sure that the JMSXUserId is protected from spoofing. I will take a closer look based on your reply. Thanks, Kelly On 7/17/06, James Strachan [EMAIL PROTECTED] wrote: On 7/17/06, Sepand M [EMAIL PROTECTED] wrote: Hi, I'm trying to modify ActiveMQ so it can handle SSL connections FWIW we already support SSL connections... http://incubator.apache.org/activemq/configuring-transports.html in particular... http://incubator.apache.org/activemq/ssl-transport-reference.html and authorize access to different queues based on client IDs. We have a security plugin to perform authentication and authorization on specific destinations, details here... http://incubator.apache.org/activemq/security.html I've been looking at your JMSXUserID support ( http://incubator.apache.org/activemq/jmsxuserid.html) to see if it could be used for authentication once the connection has been established. So the purpose of the JMSXUserID feature is to be able to add a header to all JMS messages that leave a broker so that consumers receiving the message can know the authenticated user ID who sent the message. i.e. it means that a producer cannot spoof its userID when sending a message. JMSXUserID does not perform the actual authentication/authorization - thats a feature of the security plugin I mentioned above. From what I see, using the BrokerService.setPopulateJMSXUserID(true); causes the BrokerService to use a UserIDBroker, which in turn uses the ConnectionContext to retreive the userID. The problem I see is that the connection context is set in AbstractConnection.processMessage, which uses the producerId received from the message, which has been send by the producer (and is not validated by the server). This, to me, means that if the producer manages to guess a correct producerId, it will have impersonated another producer. Is this true? The clientID is the thing we use; something the client can generate itself. Though we ensure that only 1 connection that is active has a single clientID value at any point in time (so no client can pretend to be another one - its also required by the JMS spec). So I don't think it matters too much what the producerId is - unless I've misunderstood your point -- James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-2201) Configs migration: remote-deploy-*
[ http://issues.apache.org/jira/browse/GERONIMO-2201?page=all ] Prasad Kashyap updated GERONIMO-2201: - Attachment: remote-deploy-configs.patch Something wierd is going on with the remote-deploy-tomcat pom.xml. It's the exact mirror of the jetty pom.xml. While the config for jetty builds, the config for tomcat just sits there Scanning for projects.. Configs migration: remote-deploy-* -- Key: GERONIMO-2201 URL: http://issues.apache.org/jira/browse/GERONIMO-2201 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Prasad Kashyap Fix For: 1.2 Attachments: remote-deploy-configs.patch Patch will include remote-deploy-* configs into the M2 build and jetty assembly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2201) Configs migration: remote-deploy-*
[ http://issues.apache.org/jira/browse/GERONIMO-2201?page=all ] Prasad Kashyap reassigned GERONIMO-2201: Assignee: Jason Dillon Configs migration: remote-deploy-* -- Key: GERONIMO-2201 URL: http://issues.apache.org/jira/browse/GERONIMO-2201 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Prasad Kashyap Assigned To: Jason Dillon Fix For: 1.2 Attachments: remote-deploy-configs.patch Patch will include remote-deploy-* configs into the M2 build and jetty assembly. -- 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: Re: Remove GeronimoExecutor?
On 7/18/06, Aaron Mulder [EMAIL PROTECTED] wrote:
On 7/17/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
How about we just implement toString() on our Runnables, and our
thread pool can track that way? I really want to uncouple this code.
The problem is that if you forget that, or use one bit of code outside
our control (e.g. Tomcat, Jetty, etc.) you instantly get really nasty
entries on the screen that shows the statistics. At least now we can
tell which ones aren't implemented and just bundle those into an
unknown category. I'm open to alternatives, but I don't like the
toString one so much.
How about having some optional interface such as Nameable...
public interface Nameable {
/**
* Gets a human-readable name identifying this object.
*/
String getName();
/**
* Gets the unique name of this object. The object name must
comply with
* the ObjectName specification in the JMX specification.
*
* @return the unique name of this object within the server
*/
String getObjectName();}
}
Then any console related code could do an instanceof to see if the
implementation has carefully created a nice visual representation.
(Folks could use AOP to inject implementations too). This interface
can then be used across many different kinds of objects for consoles.
Then code like the work manager can stick to regular interfaces like
Executor, Runnable etc? No biggie, just a thought.
In any case, you can definitely remove GeronimoExecutor.
+1
--
James
---
http://radio.weblogs.com/0112098/
Re: [m2 build] unable to deploy remote-deploy-* configs
This issue has now been resolved.. well almost.. (except for remote-deploy-tomcat). http://issues.apache.org/jira/browse/GERONIMO-2201 Cheers Prasad On 7/17/06, Prasad Kashyap [EMAIL PROTECTED] wrote: I am trying to get remote-deploy-jetty and remote-deploy-tomcat configs into the m2 build and it is failing due to packaging/deploy error. (Anita, Jason, I did get some info off the patches in G-2067 but that didn't help me too much). It fails in 1.2 because the deployer in 1.2 has only the ServiceBuilder available to it. The same config installs successfully in a 1.1 build. In 1.1, the deployer has ServiceBuilder and EarConfigBuilder available to it. The latter successfully processes the remote-deploy's plan and deploys it. The EARConfigBuilder is missing in the collection of builders available to the deployer in 1.2. I'm trying to find out what/who puts the builders in the collection there. If anybody knows, please speak up. Cheers Prasad
Re: Creating a secure connection system and using JMSXUserID support
On 7/18/06, Kelly Campbell [EMAIL PROTECTED] wrote: Thanks James, I'm mentoring Sepand on this project within our company, so I'll try to explain what we're trying to do. We want to use SSL client-side certificates to provide the authentication mechanism rather than user/pass or other authentication, so he is working to extend the SSL transport to do that. We already have an existing system using this for https web services style requests, and want to use the same mechanism with ActiveMQ. Does this seem like a reasonable extension? Sure, sounds good to me. This kinda thing has come up a little in the past; I think we need to add an extra field to the ConnectionInfo (the command sent to the broker to 'login' a connection to the broker) so that we can support alternative authentication mechanisms. e.g. to send along a passcode, token, certificate or whatever as a parameter to the ConnectionInfo. (To maintain backwards compatibility with the OpenWire format we could maybe create a derivation of ConnectionInfo for use with SSO or SSL based authentication). I haven't had time to study the part of the code he's asking about in depth, but it sounds like we are not sure that the JMSXUserId is protected from spoofing. I will take a closer look based on your reply. Cool - there could possibly be a hole in there somewhere, so please do double check. The contract of JMSXUserId should just be for the broker to rubber stamp messages with the clientID of the already-authenticated ConnectionInfo. -- James --- http://radio.weblogs.com/0112098/
