[jira] Closed: (GERONIMO-782) ejb ws deployment system does not use gbean builder references
[ http://issues.apache.org/jira/browse/GERONIMO-782?page=all ] David Jencks closed GERONIMO-782: - Resolution: Fixed Step 4, clean up openejb code calling WebServiceBuilder. Checking in modules/openejb-builder/src/java/org/openejb/deployment/OpenEJBModuleBuilder.java; new revision: 1.49; previous revision: 1.48 Checking in modules/openejb-builder/src/java/org/openejb/deployment/SessionBuilder.java; new revision: 1.30; previous revision: 1.29 ejb ws deployment system does not use gbean builder references -- Key: GERONIMO-782 URL: http://issues.apache.org/jira/browse/GERONIMO-782 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0-M5 The ejb builder uses static methods on AxisServiceBuilder rather than the gbean interface exposed by AxisBuilder. Fixing this in a reasonable amount of time will require removing xfire support. David Blevins has indicated that the xfire support needs to be completely rewritten anyway so I will proceed with this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-793) xmlbeans has taken over the xmlbeans 2 maven plugin. We should use their copy.
[ http://issues.apache.org/jira/browse/GERONIMO-793?page=all ] David Jencks closed GERONIMO-793: - Resolution: Fixed switched. Sendingmodules/axis-builder/project.xml Sendingmodules/client-builder/project.xml Sendingmodules/connector-builder/project.xml Sendingmodules/j2ee-builder/project.xml Sendingmodules/j2ee-schema/project.xml Sendingmodules/naming-builder/project.xml Sendingmodules/security-builder/project.xml Sendingmodules/service-builder/project.xml Sendingmodules/web-builder/project.xml Deleting plugins/maven-xmlbeans-plugin Deleting plugins/maven-xmlbeans2-plugin Transmitting file data .svn: Commit succeeded, but other errors follow: svn: Error bumping revisions post-commit (details follow): (no details printed) Checking in modules/openejb-builder/project.xml; new revision: 1.31; previous revision: 1.30 Checking in modules/pkgen-builder/project.xml; new revision: 1.5; previous revision: 1.4 xmlbeans has taken over the xmlbeans 2 maven plugin. We should use their copy. --- Key: GERONIMO-793 URL: http://issues.apache.org/jira/browse/GERONIMO-793 Project: Geronimo Type: Improvement Components: buildsystem Versions: 1.0-M5 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0-M5 xmlbeans has taken over our maven xmlbeans2 plugin. We should use their version. -- 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
mysterious svn message
Anyone have any idea what this might mean? Transmitting file data .svn: Commit succeeded, but other errors follow: svn: Error bumping revisions post-commit (details follow): no details were printed after this. No revision number, either. thanks david jencks
[jira] Closed: (GERONIMO-765) DriverManager is totally unsuited to enterprise software, and use in tranql-connector causes classloader problems
[ http://issues.apache.org/jira/browse/GERONIMO-765?page=all ] David Jencks closed GERONIMO-765: - Resolution: Fixed Assign To: Jeremy Boynes (was: David Jencks) jeremy changed the driver based MCF to use the driver directly. Reopen if there are any more problems. DriverManager is totally unsuited to enterprise software, and use in tranql-connector causes classloader problems - Key: GERONIMO-765 URL: http://issues.apache.org/jira/browse/GERONIMO-765 Project: Geronimo Type: Bug Components: connector Versions: 1.0-M3 Reporter: David Jencks Assignee: Jeremy Boynes DriverManager will not connect to drivers that aren't in the classloader of the code that calls DriverManager. This makes use of tranql connector tricky in scenarios such as the following: config 1 uses tranql connector, connects to some db. config 2, child of config 1, uses tranql connector, tries to use a different driver. DriverManager reports it cannot find a suitable driver for the URL. The tranql connector class that is calling DriverManager is in a parent classloader of the driver. possible solutions: 1) rearrange configurations so you never have tranql connector in your parent classloader. 2) write more tranql connector classes that use datasource and pooled datasource implementations 3) dynamically generate a class at runtime in the driver's classloader or a child classloader that calls DriverManager. In order of desirability, I'd say 2, 1, 3, but I think we have to investigate (3) since this problem is just about impossible to diagnose. Thanks to Dan Debrunner for pointing out this feature of DriverManager. -- 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-793) xmlbeans has taken over the xmlbeans 2 maven plugin. We should use their copy.
[ http://issues.apache.org/jira/browse/GERONIMO-793?page=comments#action_12316571 ] David Jencks commented on GERONIMO-793: --- Commit email shows revision 224446 xmlbeans has taken over the xmlbeans 2 maven plugin. We should use their copy. --- Key: GERONIMO-793 URL: http://issues.apache.org/jira/browse/GERONIMO-793 Project: Geronimo Type: Improvement Components: buildsystem Versions: 1.0-M5 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0-M5 xmlbeans has taken over our maven xmlbeans2 plugin. We should use their version. -- 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: strange stuff with JMXConnector
I know what my hostname and ip address are ... and this isn't my address (not even close). Aaron Mulder wrote: If so, try opening a terminal or command prompt and run "hostname" and see what it gives you. Then run "nslookup (whatever hostname gave you)" and see what IP address it returns. Aaron On Fri, 22 Jul 2005, Joe Bohn wrote: I had posted earlier to the user list about a problem attempting to build Geronimo and getting a strange error from the JMX Connector. http://mail-archives.apache.org/mod_mbox/geronimo-user/200507.mbox/[EMAIL PROTECTED] At the time I thought the problem was resolved when I killed a rouge java process and submitted the build with an offline option. However, now I'm seeing the exact same error when attempting to start the server itself and there are no rouge java or javaw processes running. I was running this exact same server instance (unchanged) earlier this evening without any problems. However, it seems like something at times causes this error. I still don't know what the host "10.150.1.3" has to do with anything ... or what that address resolves to. Without the JMX Connector and RMI I can't deploy or undeploy anything. Is it possible that this is really a symptom of a slow network? What is this ip address? Any ideas? Here's the error: Booting Geronimo Kernel (in Java 1.4.2_08)... Starting Geronimo Application Server [* ] 11% 44s Starting org/apache/Geronimo/Console 22:27:35,7 54 WARN [server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Server,J2EE Server=Geronimo,j2eeType=GBean,name=JMXService] Error stopping JMXConnector after failure java.io.IOException: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: 10.150.1.3; nested exception is: java.net.ConnectException: Connection timed out: connect] at mx4j.remote.resolver.rmi.Resolver.unbindServer(Resolver.java:279) at javax.management.remote.rmi.RMIConnectorServer.stop(RMIConnectorServer.java:172) at org.apache.geronimo.jmxremoting.JMXConnector.doStop(JMXConnector.java:117) at org.apache.geronimo.jmxremoting.JMXConnector.doFail(JMXConnector.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:873) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:328) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:111) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:133) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:141) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:243) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:80) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:303) 22:27:35,754 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName="geronimo.server:J2EEApplication=null,J2EEModule=org/ apache/geronimo/Server,J2EEServer=geronimo,j2eeType=GBean,name=JMXService" java.io.IOException: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: 10.150.1.3; nested exception is: java.net.ConnectException: Connection timed out: connect] at mx4j.remote.resolver.rmi.Resolver.bindServer(Resolver.java:199) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:152) at org.apache.geronimo.jmxremoting.JMXConnector.doStart(JMXConnector.java:112) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:854) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:328) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:111) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:133) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:141) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) at
Jetty and Tomcat builds
There was some brief chatter on IRC about doing both Jetty and Tomcat builds automatically and having a separate dist directory. I just wanted to take the opportunity to remind folk about the packaging and assembly plugins and what they were trying to achieve. Sometime last year we discussed replacing the assembly module and its huge maven script with a more modular structure that separated out the deployment steps from the final assembly. Each plan would be built as a distinct maven module (under the configs top-level directory) and then these pre-built configurations would be assembled together into various distributions (under the assemblies directory). The packaging plugin supports the first step: it runs within maven, converting deployment plans to configuration bundles as output artifacts which get placed in maven's repository. Maven's dependency system ensures that they get built in the right order. The assembly plugin supports the second step: assembling a final distribution out of artifacts (both dependencies and pre-built configuration bundles) taken from the maven repo. These were intended to support things like different Jetty vs. Tomcat builds by allowing the Jetty or Tomcat bits to be placed in their own plans that could be packaged once and used in different distributions as needed. I made a start on this in the Spring but ran into a couple of bugs in the kernel: * Dependency information is lost for executable configs and this prevents the maven-based builder from loading the tree properly. At runtime these depdencies are loaded from the manifest classpath, but at build time the relative paths can't be resolved properly * The regular deployer works around this by using the classloader that loaded the Configuration class as the root of the classloading tree. This works when everything is using the same dependencies (and the same versions of them) but does not allow cross-version builds (which can happen when the packager is running as a plugin). * The classloading tree is not flexible enough to allow the Jetty/Tomcat specific components to be broken out into separate bundles. Some form of import/export mechanism similar to OSGi's is needed. These aren't hard but are pretty low-level and it didn't seem a good idea to start messing in these areas on the run up to CTS. Given the recent issues with trying to get two distributions going it might be worth reopening them. -- Jeremy
Re: Web Console: Portlet Review
Cool stuff.
For the initial kernel reference you can get it from the JNDI ENC.
Just add an env entry of type org.apache.geronimo.kernel.Kernel
with no value and the deployment code will automatically put the
kernel there.
-dain
On Jul 22, 2005, at 10:11 PM, Aaron Mulder wrote:
Well, I actually worked with a couple portlets today. For
starters, I think the diff at the bottom of this message speaks
volumes
about why a management API based on interfaces is nice. It takes out
Strings, constants to hold the Strings, the Kernel variable, and
various
casts, and instead stores things like the current Server and JVM in
the
session and queries them to get the data it needs. The code is
smaller
and more reliable. :)
As for the old code, I'm not thrilled with it even besides the
kernel invocations, for a couple reasons (and I just looked at the two
portlets on the front Server Info page so far):
- The portlets that need to use a Kernel keep one in a local
variable,
and populate it by manually looking up a kernel during
initialization. I
would really have preferred to see common get kernel logic at
least, if
not a common utility to hold the current kernel.
- The portlets assume they are running within the server in question,
doing things like calling System.getProperties to get the server's
system properties (and also using a local kernel, of course). While I
have to agree that it works for now, I don't think it's any harder to
write this so it would work against a remote server, and it ends up
being
cleaner anyway.
- The portlets store data in static variables, even though they
are not
reused from request to request. My J2EE application multithreading
sensors are going off, though I don't know for sure whether a portlet
instance can service more than one request at a time. But I also
don't
like using static variables for what is otherwise a totally stateless
class, and there's especially no reason to if they are reassigned
at the
beginning of every request.
- Many of the kernel invocations returning objects are just popped
into a
collection without casting, which is almost as bad as casting, because
then there's no assurance that if the JSP needed a particular type
to be
there, the value would be of the right type. Of course the JSPs I
looked
just print objects and don't care about type.
- The JSP for printing system properties, for example, has
separate lines
for every individual property, and manually sets the background
style for
each, to achieve the alternating row color. There are just so many
better
ways to do this, that take advantage of, say, a loop, and don't
involve
needing to manually restyle every row after inserting a new row,
and so
on.
Anyway, I think the portlets are going to need a bit of attention.
That's OK I guess, since I'd like to migrate most of them to the new
management API anyway, so we'll have occasion to touch them, but I
figured
I'd give my thoughts on where things stand.
Thanks,
Aaron
Index: console-standard/src/java/org/apache/geronimo/console/
infomanager/ServerInfoPortlet.java
===
--- console-standard/src/java/org/apache/geronimo/console/
infomanager/ServerInfoPortlet.java(revision 224404)
+++ console-standard/src/java/org/apache/geronimo/console/
infomanager/ServerInfoPortlet.java(working copy)
@@ -22,7 +22,6 @@
import java.util.HashMap;
import java.util.Map;
-import javax.management.ObjectName;
import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;
import javax.portlet.GenericPortlet;
@@ -33,56 +32,22 @@
import javax.portlet.RenderResponse;
import javax.portlet.WindowState;
-import org.apache.geronimo.console.util.ObjectNameConstants;
-import org.apache.geronimo.kernel.Kernel;
-import org.apache.geronimo.kernel.KernelRegistry;
+import org.apache.geronimo.console.util.PortletManager;
+import org.apache.geronimo.j2ee.management.geronimo.JVM;
+/**
+ * Calculates various information about the server to display in
the server
+ * info portlet view (on of several JSPs depending on the portlet
state).
+ *
+ * @version $Rev: 46019 $ $Date: 2004-09-14 05:56:06 -0400 (Tue,
14 Sep 2004) $
+ */
public class ServerInfoPortlet extends GenericPortlet {
-
-public static final String SVRINFO_BASEDIR = baseDirectory;
-
-public static final String SVRINFO_VERSION = version;
-
-public static final String SVRINFO_BUILDDATE = buildDate;
-
-public static final String SVRINFO_BUILDTIME = buildTime;
-
-public static final String SVRINFO_COPYRIGHT = copyright;
-
-public static final String SVRINFO_PLATFORMARCH = platformArch;
-
-public static final String SVRINFO_GERONIMO_BUILD_VERSION =
geronimoBuildVersion;
-
-public static final String SVRINFO_GERONIMO_SPEC_VERSION =
geronimoSpecVersion;
-
-public static final String SVRINFO_PORTAL_CORE_VERSION =
[jira] Created: (GERONIMO-803) Deploy failure during redeploy leaves app undeployed
Deploy failure during redeploy leaves app undeployed Key: GERONIMO-803 URL: http://issues.apache.org/jira/browse/GERONIMO-803 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M3 Reporter: Aaron Mulder Fix For: 1.0 Ouch, this is a nasty one. If you deploy app Foo, then change it to be broken (invalid DD, whatever) and redeploy it, it goes like this: 1) undeploy old one 2) try to deploy new one 3) fail The result is that the old one has been undeployed but the new one hasn't been deployed. It would be ideal if we could try the deploy operation first, and only if it appears valid, undeploy the old version and start the new version. I'm not sure how that could be done. -- 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-804) Redeploy should calculate ModuleID to replace if not provided
Redeploy should calculate ModuleID to replace if not provided - Key: GERONIMO-804 URL: http://issues.apache.org/jira/browse/GERONIMO-804 Project: Geronimo Type: Improvement Versions: 1.0-M3 Reporter: Aaron Mulder Fix For: 1.0 When you redeploy, it would be nice to pull the configId or archive name or whatever we usually do to generate the moduleID. That way if you redeploy the same archive, it would automatically know what ModuleIDs to replace, instead of you needing to specify them on the command line. Of course this may be a little tricky since the configId is on a different XML file for every module type... As a workaround, it would be possible for the deployer to remember the module IDs generated for the archive name used for each distribute or deploy operation, and prompt you based on that if you neglect to specify a module ID on the command line (Last time you deployed 'foo.war' it was called 'MyFooWebApp'. Replace 'MyFooWebApp' (Y/n)?) -- 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: Jetty and Tomcat builds
Jeremy Boynes wrote: These aren't hard but are pretty low-level and it didn't seem a good idea to start messing in these areas on the run up to CTS. Given the recent issues with trying to get two distributions going it might be worth reopening them. Go Jeremy, Go!! -- Jeremy
[jira] Assigned: (GERONIMO-757) Move from jUDDI SNAPSHOT to formal version
[ http://issues.apache.org/jira/browse/GERONIMO-757?page=all ] Jeremy Boynes reassigned GERONIMO-757: -- Assign To: Geir Magnusson Jr (was: Jeremy Boynes) Geir is going to test with jUDDI 0.9rc4 before upgrading Move from jUDDI SNAPSHOT to formal version -- Key: GERONIMO-757 URL: http://issues.apache.org/jira/browse/GERONIMO-757 Project: Geronimo Type: Task Components: dependencies Versions: 1.0-M4 Reporter: John Sisson Assignee: Geir Magnusson Jr Fix For: 1.0-M4 Doing a search it is a dependency in the following files: geronimo/assemblies/j2ee-server/project.xml geronimo/modules/assembly/project.xml commented out in geronimo/modules/assembly/src/plan/j2ee-client-plan.xml used as a dependency in geronimo/applications/uddi-server/src/webapp/WEB-INF/geronimo-web.xml Is anything else using jUDDI at the moment? -- 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-755) Move from Scout (JAXR) version 1.0-SNAPSHOT to a formal version
[ http://issues.apache.org/jira/browse/GERONIMO-755?page=all ] Jeremy Boynes reassigned GERONIMO-755: -- Assign To: Geir Magnusson Jr (was: Jeremy Boynes) After discussion on Scout Dev we think we're ready for a release but Geir is going to a final test of HEAD with jUDDI 0.9rc4 before cutting the release. Once that is done we will roll the new release into Geronimo Move from Scout (JAXR) version 1.0-SNAPSHOT to a formal version --- Key: GERONIMO-755 URL: http://issues.apache.org/jira/browse/GERONIMO-755 Project: Geronimo Type: Task Components: dependencies Versions: 1.0-M4 Reporter: John Sisson Assignee: Geir Magnusson Jr Fix For: 1.0-M4 Doing a search it is referenced by: geronimo/assemblies/j2ee-server/project.xml geronimo/modules/assembly/project.xml geronimo/modules/webservices/project.xml geronimo/specs/jaxr/project.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Web Console JIRA Issues Stuff
Aaron, Please start a fresh email instead of appending to a Jira issue. I tend to toss Jira notes into the trash w/out a second look. Regards, Alan On 7/22/2005 2:55 PM, Aaron Mulder wrote: All, Joe Bohn filed a couple bugs in JIRA. Joe, I'm not sure if you're looking to work on these, or just record the improvements you think we should make. In any case, if someone wants to work on the console, please write to the dev list and say what you'd like to work on, so we know what's underway. You can post any patches you come up with to a JIRA issue. That said, here are my thoughts on Joe's issues: 794 -- I think the console should show all J2EE application deployments, including the Console, JMX Debug Tool, and other Geronimo applications. I woudl agree that non-application configurations should be shown separately. I put my vision for this on the Wiki: http://wiki.apache.org/geronimo/Web_Console (see Proposed Content) 795 -- I'm not sold on minimize and maximize as a high priority -- I'd rather lay things out nicely to begin with. But I wouldn't stop someone from working on this if that's their itch. :) 796 -- That's... unfortunate. Aaron On Fri, 22 Jul 2005, Joe Bohn (JIRA) wrote: List only installed applications that are not part of Geronimo itself -- Key: GERONIMO-794 URL: http://issues.apache.org/jira/browse/GERONIMO-794 Project: Geronimo Type: Improvement Components: management Versions: 1.0-M5 Environment: all Reporter: Joe Bohn A user should only see applications that they installed when accessing the list of installed applications from the admin console. We can still show the system applications but under an additional portet that by default is minimized on the page. -- 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: Web Console JIRA Issues Stuff
On Sat, 23 Jul 2005, Alan D. Cabrera wrote: Please start a fresh email instead of appending to a Jira issue. I tend to toss Jira notes into the trash w/out a second look. I'm not sure whose problem that actually is. :) At a minimum, perhaps you could review the subject line and not trash those that don't start with [jira]. Aaron On 7/22/2005 2:55 PM, Aaron Mulder wrote: All, Joe Bohn filed a couple bugs in JIRA. Joe, I'm not sure if you're looking to work on these, or just record the improvements you think we should make. In any case, if someone wants to work on the console, please write to the dev list and say what you'd like to work on, so we know what's underway. You can post any patches you come up with to a JIRA issue. That said, here are my thoughts on Joe's issues: 794 -- I think the console should show all J2EE application deployments, including the Console, JMX Debug Tool, and other Geronimo applications. I woudl agree that non-application configurations should be shown separately. I put my vision for this on the Wiki: http://wiki.apache.org/geronimo/Web_Console (see Proposed Content) 795 -- I'm not sold on minimize and maximize as a high priority -- I'd rather lay things out nicely to begin with. But I wouldn't stop someone from working on this if that's their itch. :) 796 -- That's... unfortunate. Aaron On Fri, 22 Jul 2005, Joe Bohn (JIRA) wrote: List only installed applications that are not part of Geronimo itself -- Key: GERONIMO-794 URL: http://issues.apache.org/jira/browse/GERONIMO-794 Project: Geronimo Type: Improvement Components: management Versions: 1.0-M5 Environment: all Reporter: Joe Bohn A user should only see applications that they installed when accessing the list of installed applications from the admin console. We can still show the system applications but under an additional portet that by default is minimized on the page. -- 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: Web Console JIRA Issues Stuff
On 7/23/2005 11:15 AM, Aaron Mulder wrote: On Sat, 23 Jul 2005, Alan D. Cabrera wrote: Please start a fresh email instead of appending to a Jira issue. I tend to toss Jira notes into the trash w/out a second look. I'm not sure whose problem that actually is. :) At a minimum, perhaps you could review the subject line and not trash those that don't start with [jira]. That's an idea. But, I think that my email reader threads these things. Regards, Alan
[jira] Created: (GERONIMO-805) System Log Viewer portlet s-s-sucks!
System Log Viewer portlet s-s-sucks! Key: GERONIMO-805 URL: http://issues.apache.org/jira/browse/GERONIMO-805 Project: Geronimo Type: Bug Components: management Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.0 - doesn't let you say last N records - doesn't let you skip the end value or input an end value larger than the displayed line count (as if the log won't continue to grow!) - doesn't show line numbers of the matching lines - doesn't let you specify bounds by time range (which it does at least show). - shows stack traces as a single super-long line/message, forcing the page to be unacceptably wide - filtering on log level actually greps the entire line for the log level, so a search on WARN finds a message like 13:45:11,760 DEBUG [SmapUtil$SDEInstaller] 277 read class attr -- 'WARN '. - searching on a level returns ONLY that level, not that level and higher - viewing a log file with less than a day's content (90k lines) causes an OutOfMemoryError in the server (and viewing via the web site should in any case cap to some reasonable number of lines, = 1000?) -- 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
EJB jar deployment problem
I developed a simple test EJB with Eclipse Webtools RC1. WTP has the option of creating separate EJB jar and EJB client jar projects so that in the end the deployment looks like this (ejbClient.jar is packaged inside the ejb.jar). ejb.jar: META-INF/ejb-jar.xml META-ING/MANIFEST.MF test/TestEJB.class ejbClient.jar ejbClient.jar: test/TestHome.class test/Test.class MANIFEST.MF entry has a reference to the ejbClient.jar and ejb-jar.xml has the ejb-client-jar -element. However, when I try to deploy this standalone ejb.jar into Geronimo it fails with an error message saying that it cannot find test.TestHome. Is this kind of packaging supported by Geronimo/J2EE 1.4 or should I redirect this to WTP dev and point out that they have it wrong. * Janne Kario
Re: EJB jar deployment problem
I think this may be an error in your configuration, and if not, then a bug in WTP. When exporting the ear in wtp, the client.jar and the ejbjar should be packaged directly underneath the ear. I just tried this (I'm not sure which wtp build I have, within the past week though) and my export was correct. Janne Kario wrote: I developed a simple test EJB with Eclipse Webtools RC1. WTP has the option of creating separate EJB jar and EJB client jar projects so that in the end the deployment looks like this (ejbClient.jar is packaged inside the ejb.jar). ejb.jar: META-INF/ejb-jar.xml META-ING/MANIFEST.MF test/TestEJB.class ejbClient.jar ejbClient.jar: test/TestHome.class test/Test.class MANIFEST.MF entry has a reference to the ejbClient.jar and ejb-jar.xml has the ejb-client-jar -element. However, when I try to deploy this standalone ejb.jar into Geronimo it fails with an error message saying that it cannot find test.TestHome. Is this kind of packaging supported by Geronimo/J2EE 1.4 or should I redirect this to WTP dev and point out that they have it wrong. * Janne Kario
