[jira] Created: (GERONIMODEVTOOLS-199) javax.xml.bind is not included in server runtime library
javax.xml.bind is not included in server runtime library Key: GERONIMODEVTOOLS-199 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-199 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tomasz Mazan JAX-B classes/annotation are not included in default Geronimo's server runtime so user must include single jar to use i.e. XmlElement to annotate classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2188) When oracle wrapper is used, commits are not immediately committed to oracle database
[ https://issues.apache.org/jira/browse/GERONIMO-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526162 ] Lin Sun commented on GERONIMO-2188: --- Hi David, check the G2188-latest.patch file, which contains what I propose. Seems you applied portions of it in tranql trunk and that portion didn't make things work yet. Please let me know if you have any other questions, Thanks, Lin When oracle wrapper is used, commits are not immediately committed to oracle database - Key: GERONIMO-2188 URL: https://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 Assignee: David Jencks Attachments: G2188-2.patch, G2188-latest.patch, G2188.patch 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. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (GERONIMO-2880) TransportDisposedIOException occurs when trying to close ActiveMQ queue
Hi Aman,I have made the log level to ERROR in
TransportConnection.OneJIRA is opened in ActiveMQ project for it.
https://issues.apache.org/activemq/browse/AMQ-1384
For your doubt on how to set AUTOCOMMIT to off, I am not sure whether
activemq ra has such a property. f your requirement is to send a set of
messages to JMS broker as an atomic unit,then you can use a transacted jms
session.
On 9/5/07, Aman Nanner (JIRA) [EMAIL PROTECTED] wrote:
[
https://issues.apache.org/jira/browse/GERONIMO-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525138]
Aman Nanner commented on GERONIMO-2880:
---
Hi Anish,
As per my last comment, I had discovered that the exception was being
generated because the connection was already closed by ActiveMQ due to an
error that occurred during the sending of the last message. This error
message did not appear in my log because my logging threshold was set above
DEBUG, so I had suggested that errors that occur during the sending of
message should perhaps be logged at a higher threshold level (such as WARN
or ERROR).
Also, the source problem was this:
{{java.io.IOException: Cannot set AUTOCOMMIT ON when in an XA
connection.}}
Does anybody know how to set AUTOCOMMIT to off for the JMS resource
adapter?
TransportDisposedIOException occurs when trying to close ActiveMQ queue
---
Key: GERONIMO-2880
URL: https://issues.apache.org/jira/browse/GERONIMO-2880
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: ActiveMQ
Affects Versions: 2.0.x
Environment: Windows XP SP2
Reporter: Aman Nanner
Priority: Critical
Fix For: 2.0.x, 2.1
I have discovered some problems with queues while running unittest in
our own J2EE app.
After sending a message on a queue, when we try to call the close()
method on the queue, we get the following exception:
org.apache.activemq.transport.TransportDisposedIOException: Peer
(vm://localhost#69) disposed.
where the number after localhost is different every time.
We do not experience this problem with topics. We are using ActiveMQ as
part of an embedded configuration with Geronimo.
I've done some debugging and the problem occurs at this line in the
ActiveMQMessageProducer.close() method:
this.session.asyncSendPacket(info.createRemoveCommand());
The queue itself is disposed properly in the dispose() method that is
called in the line before, but this sending of the asynchronous packet
fails.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
--
Best Regards,
Anish Pathadan
Re: New GShell-based Geronimo Server launcher now in server/trunk
This is really cool stuff, I'm pretty blown away. I'm convinced that a significant percentage of app server administrators prefer a power scripting interface over a fancy UI, so now Geronimo can offer both. I seem to recall some discussion about supporting multiple scripting languages.. but I can't find anything in the dev archives though so maybe I am imagining that? Either way, I think groovy is certainly adequate. Best wishes, Paul On Sep 8, 2007, at 3:40 PM, Jason Dillon wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../ lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of course, all of these could have been run from a single ./bin/ gsh, but just for clarity, you can run them one off too. Maybe list or mange the configurations ./bin/gsh list-configurations ./bin/gsh remove-configuration some-unwanted-config ./bin/gsh copy-configuration default some-new-config The sky is the limit really... for what kind of management we can do... Lets say you wanted to do the above on a remote node? ./bin/gsh remote-shell someserver:9443 Connecting to someserver:9447... Connected username: system password: (remember this is all jline, so we can mask passwords like one woudl expect) someserver:9447 list-configurations someserver:9447 remove-configuration some-unwanted-config someserver:9447 copy-configuration default some-new-config So, all of these operations would happen on the node named someserver listening on 9443 (over ssl of course). Or how about you want to reboot a server remotely? someserver:9447
[jira] Created: (GERONIMO-3461) Disable MEJB gbean in the default assemblies until G3456 is fixed
Disable MEJB gbean in the default assemblies until G3456 is fixed - Key: GERONIMO-3461 URL: https://issues.apache.org/jira/browse/GERONIMO-3461 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 2.0.1, 2.1 Reporter: Donald Woods Assignee: Donald Woods Fix For: 2.0.2, 2.1 Temporarily disable the MEJB bean due to the security exposure found by Anita, until GERONIMO-3456 is properly fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-200) javax.xml.soap not included in geronimo runtime library
javax.xml.soap not included in geronimo runtime library --- Key: GERONIMODEVTOOLS-200 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-200 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tomasz Mazan javax.xml.soap not included in geronimo runtime library by default. User have to import single jar to project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-200) javax.xml.soap not included in geronimo runtime library
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526170 ] Kan Ogawa commented on GERONIMODEVTOOLS-200: Tomasz, About JEE5-spec-api library classpath issue, GERONIMODEVTOOLS-175 was already posted. Including your posted GERONIMODEVTOOLS-199, how about resolving them together ? For details, see the GERONIMODEVTOOLS-175 issue. Thanks, Kan Ogawa javax.xml.soap not included in geronimo runtime library --- Key: GERONIMODEVTOOLS-200 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-200 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tomasz Mazan javax.xml.soap not included in geronimo runtime library by default. User have to import single jar to project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3462) Problem with throwing SOAPFaultException within WebService based on SessionBean
Problem with throwing SOAPFaultException within WebService based on SessionBean
Key: GERONIMO-3462
URL: https://issues.apache.org/jira/browse/GERONIMO-3462
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: webservices
Affects Versions: 2.0.1
Environment: ApacheCXF as service provider
Reporter: Tomasz Mazan
I create SOAPFaultException using code below:
public SOAPFaultException createFault(String errorCode, String
errorString) {
SOAPFault fault = null;
try {
fault = SOAPFactory.newInstance().createFault();
fault.setFaultCode(new QName(foo, bar, abc));
fault.setFaultString(errorString);
fault.setFaultActor(ACTOR);
} catch (SOAPException ex) {
return new SOAPFaultException(null);
}
return new SOAPFaultException(fault);
}
and my WebMethod returns this exception in case internal exception:
@WebService(serviceName = MyService, portName = CustomerServices)
@Stateless(name = MyCustomerService)
public class MyCustomerService {
@EJB
private CoreManager coreManager = null;
public MyCustomerService() {
}
@WebMethod(operationName = createCustomer)
public Customer createCustomer(@WebParam(name = identifier) String
identifier) throws SOAPFaultException {
try {
return this.coreManager.createCustomer(identifier);
} catch (ServiceException e) {
throw this.faultService.createFault(FAULT CODE,
FAULT STRING);
}
}
}
and client catches fault with attributes:
[faultstring]=
string(298) java.rmi.RemoteException: The bean encountered a non-application
exception.; nested exception is:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean
encountered a non-application exception.; nested exception i
s:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING
[faultcode]=
string(11) soap:Server
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3462) Problem with throwing SOAPFaultException within WebService based on SessionBean
[
https://issues.apache.org/jira/browse/GERONIMO-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Mazan updated GERONIMO-3462:
---
Description:
I create SOAPFaultException using code below:
{noformat}
public SOAPFaultException createFault(String errorCode, String
errorString) {
SOAPFault fault = null;
try {
fault = SOAPFactory.newInstance().createFault();
fault.setFaultCode(new QName(foo, bar, abc));
fault.setFaultString(errorString);
fault.setFaultActor(ACTOR);
} catch (SOAPException ex) {
return new SOAPFaultException(null);
}
return new SOAPFaultException(fault);
}
{noformat}
and my WebMethod returns this exception in case internal exception:
{noformat}
@WebService(serviceName = MyService, portName = CustomerServices)
@Stateless(name = MyCustomerService)
public class MyCustomerService {
@EJB
private CoreManager coreManager = null;
public MyCustomerService() {
}
@WebMethod(operationName = createCustomer)
public Customer createCustomer(@WebParam(name = identifier) String
identifier) throws SOAPFaultException {
try {
return this.coreManager.createCustomer(identifier);
} catch (ServiceException e) {
throw this.faultService.createFault(FAULT CODE,
FAULT STRING);
}
}
}
{noformat}
and client catches fault with attributes:
{noformat}
[faultstring]= string(298) java.rmi.RemoteException: The bean encountered
a non-application exception.; nested exception is:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean encountered a
non-application exception.; nested exception i
s: javax.xml.ws.soap.SOAPFaultException: FAULT STRING
[faultcode]= string(11) soap:Server
{noformat}
was:
I create SOAPFaultException using code below:
public SOAPFaultException createFault(String errorCode, String
errorString) {
SOAPFault fault = null;
try {
fault = SOAPFactory.newInstance().createFault();
fault.setFaultCode(new QName(foo, bar, abc));
fault.setFaultString(errorString);
fault.setFaultActor(ACTOR);
} catch (SOAPException ex) {
return new SOAPFaultException(null);
}
return new SOAPFaultException(fault);
}
and my WebMethod returns this exception in case internal exception:
@WebService(serviceName = MyService, portName = CustomerServices)
@Stateless(name = MyCustomerService)
public class MyCustomerService {
@EJB
private CoreManager coreManager = null;
public MyCustomerService() {
}
@WebMethod(operationName = createCustomer)
public Customer createCustomer(@WebParam(name = identifier) String
identifier) throws SOAPFaultException {
try {
return this.coreManager.createCustomer(identifier);
} catch (ServiceException e) {
throw this.faultService.createFault(FAULT CODE,
FAULT STRING);
}
}
}
and client catches fault with attributes:
[faultstring]=
string(298) java.rmi.RemoteException: The bean encountered a non-application
exception.; nested exception is:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean
encountered a non-application exception.; nested exception i
s:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING
[faultcode]=
string(11) soap:Server
Problem with throwing SOAPFaultException within WebService based on
SessionBean
Key: GERONIMO-3462
URL: https://issues.apache.org/jira/browse/GERONIMO-3462
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.0.1
Environment: ApacheCXF as service provider
Reporter: Tomasz Mazan
I create SOAPFaultException using code below:
{noformat}
public SOAPFaultException createFault(String errorCode, String
errorString) {
SOAPFault fault = null;
try {
fault = SOAPFactory.newInstance().createFault();
fault.setFaultCode(new QName(foo, bar, abc));
fault.setFaultString(errorString);
fault.setFaultActor(ACTOR);
} catch (SOAPException ex) {
return new
XML Schemas on the site
Are there any plans to put the schemas for 2.0.1 here: http://geronimo.apache.org/xml-schemas.html Thanks Anita Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
Re: Schema issues
On 9/7/07, David Jencks [EMAIL PROTECTED] wrote: On Sep 7, 2007, at 10:38 AM, Jarek Gawor wrote: I was collecting the different schema files used by Geronimo to publish them on a web site and I noticed one thing with the plugins-1.2 xsd. First, it imports attributes-1.1.xsd and not attributes-1.2.xsd. And that's fine. That's what 2.0.1 came out with. But in trunk the plugins-1.2.xsd was updated to import attributes-1.2.xsd. I don't think that is right as it will break compatibility. I think we should create plugins-1.3.xsd (with -1.3 namespace) which then can import the attributes-1.2.xsd (and switch the plugins-1.2.xsd to the version in branches/2.0). I guess I didn't notice that 2.0.1 was going out with something called plugins-1.2 when I started working on GERONIMO-3330 which also included a rather different plugins-1.2. I'll see about renaming the file in trunk to plugins-1.3 although it might take me a few days. I see you already took care of it. Thanks! I also validated the rest of the .xsd files and for the most part they validate ok. A few of them ( geronimo-web-2.0.xsd, geronimo-jetty-2.0.xsd, and geronimo-tomcat-2.0.xsd) import persistence-1.0.xsd as a local file. I can't find that file anywhere in Geronimo. Should I update these Geronimo .xsd files to refer to http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd or should we pull it in locally? I'm not sure what you mean by refer to... but either one is fine with me as long as I don't have to deal with any questions about whether CDDL licensed source files can be in apache svn. It looks like the current draft of the 3rd party licensing policy would allow us to include a cddl licensed persistence_1_0.xsd: http://people.apache.org/~rubys/3party.html redirected from http://www.apache.org/legal/3party.html By refer, I meant changing the schemaLocation to http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd which will cause the schema file to be pulled from Sun's site. I'll go ahead and update the schemaLocation unless somebody objects first. Jarek
[jira] Updated: (GERONIMODEVTOOLS-199) javax.xml.bind is not included in server runtime library
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-199: --- Fix Version/s: 2.0 Assignee: Tim McConnell javax.xml.bind is not included in server runtime library Key: GERONIMODEVTOOLS-199 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-199 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tomasz Mazan Assignee: Tim McConnell Fix For: 2.0 JAX-B classes/annotation are not included in default Geronimo's server runtime so user must include single jar to use i.e. XmlElement to annotate classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-200) javax.xml.soap not included in geronimo runtime library
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-200: --- Fix Version/s: 2.0 Assignee: Tim McConnell javax.xml.soap not included in geronimo runtime library --- Key: GERONIMODEVTOOLS-200 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-200 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tomasz Mazan Assignee: Tim McConnell Fix For: 2.0 javax.xml.soap not included in geronimo runtime library by default. User have to import single jar to project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: XML Schemas on the site
YES. I think Jarek already moved all the schemas (https://svn.apache.org/repos/asf/geronimo/site/trunk/docs/schemas-2.0/) so I'll be updating the web site soon. Cheers! Hernan Anita Kulshreshtha wrote: Are there any plans to put the schemas for 2.0.1 here: http://geronimo.apache.org/xml-schemas.html Thanks Anita Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
[jira] Assigned: (GERONIMO-3462) Problem with throwing SOAPFaultException within WebService based on SessionBean
[
https://issues.apache.org/jira/browse/GERONIMO-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor reassigned GERONIMO-3462:
-
Assignee: Jarek Gawor
Problem with throwing SOAPFaultException within WebService based on
SessionBean
Key: GERONIMO-3462
URL: https://issues.apache.org/jira/browse/GERONIMO-3462
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.0.1
Environment: ApacheCXF as service provider
Reporter: Tomasz Mazan
Assignee: Jarek Gawor
I create SOAPFaultException using code below:
{noformat}
public SOAPFaultException createFault(String errorCode, String
errorString) {
SOAPFault fault = null;
try {
fault = SOAPFactory.newInstance().createFault();
fault.setFaultCode(new QName(foo, bar, abc));
fault.setFaultString(errorString);
fault.setFaultActor(ACTOR);
} catch (SOAPException ex) {
return new SOAPFaultException(null);
}
return new SOAPFaultException(fault);
}
{noformat}
and my WebMethod returns this exception in case internal exception:
{noformat}
@WebService(serviceName = MyService, portName = CustomerServices)
@Stateless(name = MyCustomerService)
public class MyCustomerService {
@EJB
private CoreManager coreManager = null;
public MyCustomerService() {
}
@WebMethod(operationName = createCustomer)
public Customer createCustomer(@WebParam(name = identifier) String
identifier) throws SOAPFaultException {
try {
return this.coreManager.createCustomer(identifier);
} catch (ServiceException e) {
throw this.faultService.createFault(FAULT CODE,
FAULT STRING);
}
}
}
{noformat}
and client catches fault with attributes:
{noformat}
[faultstring]= string(298) java.rmi.RemoteException: The bean
encountered a non-application exception.; nested exception is:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean encountered a
non-application exception.; nested exception i
s: javax.xml.ws.soap.SOAPFaultException: FAULT STRING
[faultcode]= string(11) soap:Server
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3463) c:forEach does not work with deferred expression
c:forEach does not work with deferred expression
Key: GERONIMO-3463
URL: https://issues.apache.org/jira/browse/GERONIMO-3463
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 2.0.1
Environment: Fedora7, Sun JDK 1.6.0_02, geronimo-tomcat6-jee5-2.0.1
Reporter: Piotr Piotrowski
The following page works on SunApplication Server 9, but does not work on
Geronimo:
[EMAIL PROTECTED] contentType=text/html%
[EMAIL PROTECTED] pageEncoding=UTF-8%
[EMAIL PROTECTED] prefix=f uri=http://java.sun.com/jsf/core%
[EMAIL PROTECTED] prefix=h uri=http://java.sun.com/jsf/html%
[EMAIL PROTECTED] prefix=c uri=http://java.sun.com/jsp/jstl/core%
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
head
meta http-equiv=Content-Type content=text/html; charset=UTF-8
titleJSP Page/title
/head
body
f:view
p
c:forEach var=i items=#{CombinedEL.table}
h:outputText value=#{i}/,
/c:forEach
/p
/f:view
/body
/html
The managed bean looks as follows:
package pp.web;
public class CombinedEL {
public Object[] getTable() {
return new Object[] {a, b, c};
}
}
The error looks like this:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from
fulfilling this request.
exception
javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Don't know
how to iterate over supplied items in lt;forEachgt;
javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
root cause
javax.faces.FacesException: javax.servlet.jsp.JspTagException: Don't know how
to iterate over supplied items in lt;forEachgt;
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:340)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:254)
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
root cause
javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Don't know
how to iterate over supplied items in lt;forEachgt;
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:850)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:779)
org.apache.jsp.combinedEL_jsp._jspService(combinedEL_jsp.java:90)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:388)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:334)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:254)
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
root cause
javax.servlet.jsp.JspTagException: Don't know how to iterate over supplied
items in lt;forEachgt;
org.apache.taglibs.standard.tag.common.core.ForEachSupport.toForEachIterator(ForEachSupport.java:274)
org.apache.taglibs.standard.tag.common.core.ForEachSupport.supportedTypeForEachIterator(ForEachSupport.java:238)
org.apache.taglibs.standard.tag.common.core.ForEachSupport.prepare(ForEachSupport.java:155)
javax.servlet.jsp.jstl.core.LoopTagSupport.doStartTag(LoopTagSupport.java:256)
org.apache.jsp.combinedEL_jsp._jspx_meth_c_005fforEach_005f0(combinedEL_jsp.java:157)
org.apache.jsp.combinedEL_jsp._jspx_meth_f_005fview_005f0(combinedEL_jsp.java:119)
org.apache.jsp.combinedEL_jsp._jspService(combinedEL_jsp.java:80)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:388)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
[jira] Commented: (GERONIMO-3462) Problem with throwing SOAPFaultException within WebService based on SessionBean
[
https://issues.apache.org/jira/browse/GERONIMO-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526206
]
Jarek Gawor commented on GERONIMO-3462:
---
Here's what I see:
1) SOAP fault string is set and propagated correctly. SOAP fault code is not.
Looks like a bug in CXF somewhere... will investigate more
2) The on-the-wire message looks ok to me (except the soap fault code is
incorrect) for a WS client.
3) Looks like your client is an ejb client. In an ejb client you get a
RemoteException that contains the SOAPFaultException as a root cause. So in an
ejb client you might need to do RemoteException.getCause() to get the expected
SOAPFaultException.
Problem with throwing SOAPFaultException within WebService based on
SessionBean
Key: GERONIMO-3462
URL: https://issues.apache.org/jira/browse/GERONIMO-3462
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.0.1
Environment: ApacheCXF as service provider
Reporter: Tomasz Mazan
Assignee: Jarek Gawor
I create SOAPFaultException using code below:
{noformat}
public SOAPFaultException createFault(String errorCode, String
errorString) {
SOAPFault fault = null;
try {
fault = SOAPFactory.newInstance().createFault();
fault.setFaultCode(new QName(foo, bar, abc));
fault.setFaultString(errorString);
fault.setFaultActor(ACTOR);
} catch (SOAPException ex) {
return new SOAPFaultException(null);
}
return new SOAPFaultException(fault);
}
{noformat}
and my WebMethod returns this exception in case internal exception:
{noformat}
@WebService(serviceName = MyService, portName = CustomerServices)
@Stateless(name = MyCustomerService)
public class MyCustomerService {
@EJB
private CoreManager coreManager = null;
public MyCustomerService() {
}
@WebMethod(operationName = createCustomer)
public Customer createCustomer(@WebParam(name = identifier) String
identifier) throws SOAPFaultException {
try {
return this.coreManager.createCustomer(identifier);
} catch (ServiceException e) {
throw this.faultService.createFault(FAULT CODE,
FAULT STRING);
}
}
}
{noformat}
and client catches fault with attributes:
{noformat}
[faultstring]= string(298) java.rmi.RemoteException: The bean
encountered a non-application exception.; nested exception is:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean encountered a
non-application exception.; nested exception i
s: javax.xml.ws.soap.SOAPFaultException: FAULT STRING
[faultcode]= string(11) soap:Server
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3464) A webapp with init-param fails deployment
A webapp with init-param fails deployment
---
Key: GERONIMO-3464
URL: https://issues.apache.org/jira/browse/GERONIMO-3464
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: deployment
Environment: Windows XP
Reporter: Prasad Kashyap
Assignee: David Jencks
Priority: Critical
Fix For: 2.0.2
I have a very simple web.xml whose only servlet definition contains an
init-param
{code}
servlet
display-nameAsyncServlet/display-name
servlet-nameAsyncServlet/servlet-name
servlet-classorg.apache.geronimo.AsyncServlet/servlet-class
init-param
param-nameremoteUrl/param-name
param-valuehttp://puffyshirt:8080/param-value
/init-param
/servlet
{code}
This webapp fails deployment with the following exception:
error: cvc-complex-type.2.4a: Expected elements
'[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee
[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee' instead of
'[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee' here in element
[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee
The same app deploys successfully on Tomcat
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-201) java.lang.NullPointerException at org.apache.geronimo.st.ui.internal.Trace.trace(Trace.java:74)
java.lang.NullPointerException at org.apache.geronimo.st.ui.internal.Trace.trace(Trace.java:74) --- Key: GERONIMODEVTOOLS-201 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-201 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Ted Kirby I loaded plugins into eclipse, launched them as an eclipse application, and enabled tracing and debugging, and got this traceback: Caused by: java.lang.NullPointerException at org.apache.geronimo.st.ui.internal.Trace.trace(Trace.java:74) at com.ibm.wasce.st.ui.internal.GeronimoRuntimeWizardFragment$1$1.run(GeronimoRuntimeWizardFragment.java:71) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3464) A webapp with init-param fails deployment
[
https://issues.apache.org/jira/browse/GERONIMO-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prasad Kashyap closed GERONIMO-3464.
Resolution: Invalid
Failure caused by load-on-startup preceding init-param
Guess Tomcat is more flexible.
A webapp with init-param fails deployment
---
Key: GERONIMO-3464
URL: https://issues.apache.org/jira/browse/GERONIMO-3464
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Environment: Windows XP
Reporter: Prasad Kashyap
Assignee: David Jencks
Priority: Critical
Fix For: 2.0.2
I have a very simple web.xml whose only servlet definition contains an
init-param
{code}
servlet
display-nameAsyncServlet/display-name
servlet-nameAsyncServlet/servlet-name
servlet-classorg.apache.geronimo.AsyncServlet/servlet-class
init-param
param-nameremoteUrl/param-name
param-valuehttp://puffyshirt:8080/param-value
/init-param
/servlet
{code}
This webapp fails deployment with the following exception:
error: cvc-complex-type.2.4a: Expected elements
'[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee
[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee' instead of
'[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee' here in element
[EMAIL PROTECTED]://java.sun.com/xml/ns/javaee
The same app deploys successfully on Tomcat
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3462) Problem with throwing SOAPFaultException within WebService based on SessionBean
[
https://issues.apache.org/jira/browse/GERONIMO-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526231
]
Jarek Gawor commented on GERONIMO-3462:
---
Btw, I also noticed that Axis2 EJB-based WS was returning a completely invalid
fault message in this case. This should be fixed now in trunk (revision 574341)
and branches/2.0 (revision 574343).
Even with that fix, Axis2 is also not returning the specified fault code but it
is passing the right fault string and actor.
Problem with throwing SOAPFaultException within WebService based on
SessionBean
Key: GERONIMO-3462
URL: https://issues.apache.org/jira/browse/GERONIMO-3462
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.0.1
Environment: ApacheCXF as service provider
Reporter: Tomasz Mazan
Assignee: Jarek Gawor
I create SOAPFaultException using code below:
{noformat}
public SOAPFaultException createFault(String errorCode, String
errorString) {
SOAPFault fault = null;
try {
fault = SOAPFactory.newInstance().createFault();
fault.setFaultCode(new QName(foo, bar, abc));
fault.setFaultString(errorString);
fault.setFaultActor(ACTOR);
} catch (SOAPException ex) {
return new SOAPFaultException(null);
}
return new SOAPFaultException(fault);
}
{noformat}
and my WebMethod returns this exception in case internal exception:
{noformat}
@WebService(serviceName = MyService, portName = CustomerServices)
@Stateless(name = MyCustomerService)
public class MyCustomerService {
@EJB
private CoreManager coreManager = null;
public MyCustomerService() {
}
@WebMethod(operationName = createCustomer)
public Customer createCustomer(@WebParam(name = identifier) String
identifier) throws SOAPFaultException {
try {
return this.coreManager.createCustomer(identifier);
} catch (ServiceException e) {
throw this.faultService.createFault(FAULT CODE,
FAULT STRING);
}
}
}
{noformat}
and client catches fault with attributes:
{noformat}
[faultstring]= string(298) java.rmi.RemoteException: The bean
encountered a non-application exception.; nested exception is:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean encountered a
non-application exception.; nested exception i
s: javax.xml.ws.soap.SOAPFaultException: FAULT STRING
[faultcode]= string(11) soap:Server
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3457) Drools BRMS issue using geronimo 2.0.1-jetty6
[ https://issues.apache.org/jira/browse/GERONIMO-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526236 ] Bhagwath Vadyala commented on GERONIMO-3457: Here is the exception I am getting now with drools 4.0.1 brms war file deployed on geronimo 2.0.1-jetty6 I didnot make any changes to geronimo server or drools-brms war file after downloading.I directly deployed it without any changes and i see this exception. please let me know how i can fix this error. Geronimo Application Server started Setting up the repository, registering node types etc. 15:25:28,607 ERROR [log] Failed startup of context org.mortbay.jetty.webapp.WebA [EMAIL PROTECTED]/drools-jbrms,file:/C:/geronimo-jetty6-jee5-2.0.1/repository/d efault/drools-jbrms/1189452176492/drools-jbrms-1189452176492.war/} java.lang.RuntimeException: exception invoking: create at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:131) at org.jboss.seam.Component.callComponentMethod(Component.java:1802) at org.jboss.seam.Component.callCreateMethod(Component.java:1725) at org.jboss.seam.Component.newInstance(Component.java:1714) at org.jboss.seam.contexts.Lifecycle.startup(Lifecycle.java:165) at org.jboss.seam.contexts.Lifecycle.endInitialization(Lifecycle.java:13 7) at org.jboss.seam.init.Initialization.init(Initialization.java:479) at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.j ava:33) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler. java:530) at org.mortbay.jetty.servlet.Context.startContext(Context.java:135) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.jav a:1218) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java: 500) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448 ) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java: 40) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.doStart(A bstractImmutableHandler.java:38) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java: 40) at org.apache.geronimo.jetty6.JettyWebAppContext$StartCommand.lifecycleM ethod(JettyWebAppContext.java:361) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycle Command(AbstractImmutableHandler.java:54) at org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.lifecycle Command(ThreadClassloaderHandler.java:57) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycle Command(AbstractImmutableHandler.java:52) at org.apache.geronimo.jetty6.handler.InstanceContextHandler.lifecycleCo mmand(InstanceContextHandler.java:81) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycle Command(AbstractImmutableHandler.java:52) at org.apache.geronimo.jetty6.handler.UserTransactionHandler.lifecycleCo mmand(UserTransactionHandler.java:63) at org.apache.geronimo.jetty6.handler.AbstractImmutableHandler.lifecycle Command(AbstractImmutableHandler.java:52) at org.apache.geronimo.jetty6.handler.ComponentContextHandler.lifecycleC ommand(ComponentContextHandler.java:57) at org.apache.geronimo.jetty6.JettyWebAppContext.doStart(JettyWebAppCont ext.java:330) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:553) at
[jira] Created: (GERONIMO-3465) Default log level needs to be tweaked to provide more useful information to users
Default log level needs to be tweaked to provide more useful information to users - Key: GERONIMO-3465 URL: https://issues.apache.org/jira/browse/GERONIMO-3465 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0.1 Reporter: Kevan Miller Priority: Critical Fix For: 2.0.2, 2.1 default log level is currently ERROR. This is too strict for many users. We should default to being more verbose and provide useful information to new Geronimo users/developers. Users who want less verbose output can tune their server-log4j properties accordingly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3462) Problem with throwing SOAPFaultException within WebService based on SessionBean
[
https://issues.apache.org/jira/browse/GERONIMO-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526265
]
Tomasz Mazan commented on GERONIMO-3462:
Jarek
1) According to jax-ws spec (JSR-000224) point 10.2.2.3 faultcode is correct.
Faultstring is wrapped in exception classname etc. - opposite to my
expectations.
3) My client is a php script so I'm wondering why there's
java.rmi.RemoteException
Thanks
Problem with throwing SOAPFaultException within WebService based on
SessionBean
Key: GERONIMO-3462
URL: https://issues.apache.org/jira/browse/GERONIMO-3462
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.0.1
Environment: ApacheCXF as service provider
Reporter: Tomasz Mazan
Assignee: Jarek Gawor
I create SOAPFaultException using code below:
{noformat}
public SOAPFaultException createFault(String errorCode, String
errorString) {
SOAPFault fault = null;
try {
fault = SOAPFactory.newInstance().createFault();
fault.setFaultCode(new QName(foo, bar, abc));
fault.setFaultString(errorString);
fault.setFaultActor(ACTOR);
} catch (SOAPException ex) {
return new SOAPFaultException(null);
}
return new SOAPFaultException(fault);
}
{noformat}
and my WebMethod returns this exception in case internal exception:
{noformat}
@WebService(serviceName = MyService, portName = CustomerServices)
@Stateless(name = MyCustomerService)
public class MyCustomerService {
@EJB
private CoreManager coreManager = null;
public MyCustomerService() {
}
@WebMethod(operationName = createCustomer)
public Customer createCustomer(@WebParam(name = identifier) String
identifier) throws SOAPFaultException {
try {
return this.coreManager.createCustomer(identifier);
} catch (ServiceException e) {
throw this.faultService.createFault(FAULT CODE,
FAULT STRING);
}
}
}
{noformat}
and client catches fault with attributes:
{noformat}
[faultstring]= string(298) java.rmi.RemoteException: The bean
encountered a non-application exception.; nested exception is:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean encountered a
non-application exception.; nested exception i
s: javax.xml.ws.soap.SOAPFaultException: FAULT STRING
[faultcode]= string(11) soap:Server
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
update on the pluggable admin console
Recent work on GERONIMO-3413 provides a new admin console with two main improvements: - New system modules and 3rd party plugins can dynamically add and remove their portlets in the admin console - It has a smaller footrpint and minimal requirements on what's running in the server. You can, for example, use this new console in the minimal assemblies where Dojo and many jee5 components are not present. As you customize your server the corresponding admin portlets are dynamically added/removed from the admin console. To try it out, build yourself a 2.1-SNAPSHOT minimal assembly or you can use a jee5 assembly if you undeploy the old admin console first. Then: - svn co https://svn.apache.org/repos/asf/geronimo/plugins/console/ trunk - cd trunk - mvn install - G/bin/deploy.sh install-plugin console-tomcat/target/console- tomcat-1.0-SNAPSHOT.car (for tomcat) or - G/bin/deploy.sh install-plugin console-jetty/target/console- jetty-1.0-SNAPSHOT.car (for jetty) Then at: http://localhost:8080/console you will see the base console that only has the portlets for deployment, plugin management, security, etc. The other admin portlets you might recall from the old admin console can be selectively installed from the plugins available at: https://svn.apache.org/repos/asf/geronimo/plugins using steps similar to above. Note, the directory, roller, spring, and tuscany plugins in that area of svn don't provide admin console portlets yet. Actually I don't know if those plugins are compatible with Geronimo 2.1-SNAPSHOT since David has implemented a lot of improvements to the plugin system lately. Like I mentioned above, in 2.1-SNAPSHOT the old admin console is still pre-deployed in the jee5 assemblies while we figure out how to restructure svn and the build process around the plugin concepts. The new admin console is implemented as a plugin outside of server/ trunk, so it should be easy to swap out the console bits out once we have everything else in place. If we want to support the new console in an upcoming 2.0.x release of Geronimo then David's recent changes to the car-maven-plugin, plugin schema, and plugin installer would need to be backported to the 2.0 branch, if that's appropriate. Also, I have some of the artifacts staged in my personal ASF area so that it's easier for you to build and test things out. After a few days for collecting feedback I will deploy those artifacts to the ASF snapshot repo if no major issues are identified. Various todos: - drive out the remaining bugs and rough spots. Like the JMX viewer has some problems. - fix weird http session problem in jetty, don't know if its a bug in jetty, pluto, or the console code - try to simplify the security model - update the doc on wiki - clean up poms Best wishes, Paul
[jira] Commented: (GERONIMO-3465) Default log level needs to be tweaked to provide more useful information to users
[ https://issues.apache.org/jira/browse/GERONIMO-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526266 ] Donald Woods commented on GERONIMO-3465: +10 to increasing the log level to either Warn or Info (the previous level) Default log level needs to be tweaked to provide more useful information to users - Key: GERONIMO-3465 URL: https://issues.apache.org/jira/browse/GERONIMO-3465 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.1 Reporter: Kevan Miller Priority: Critical Fix For: 2.0.2, 2.1 default log level is currently ERROR. This is too strict for many users. We should default to being more verbose and provide useful information to new Geronimo users/developers. Users who want less verbose output can tune their server-log4j properties accordingly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3462) Problem with throwing SOAPFaultException within WebService based on SessionBean
[
https://issues.apache.org/jira/browse/GERONIMO-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526267
]
Jarek Gawor commented on GERONIMO-3462:
---
What does php script call?
Problem with throwing SOAPFaultException within WebService based on
SessionBean
Key: GERONIMO-3462
URL: https://issues.apache.org/jira/browse/GERONIMO-3462
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.0.1
Environment: ApacheCXF as service provider
Reporter: Tomasz Mazan
Assignee: Jarek Gawor
I create SOAPFaultException using code below:
{noformat}
public SOAPFaultException createFault(String errorCode, String
errorString) {
SOAPFault fault = null;
try {
fault = SOAPFactory.newInstance().createFault();
fault.setFaultCode(new QName(foo, bar, abc));
fault.setFaultString(errorString);
fault.setFaultActor(ACTOR);
} catch (SOAPException ex) {
return new SOAPFaultException(null);
}
return new SOAPFaultException(fault);
}
{noformat}
and my WebMethod returns this exception in case internal exception:
{noformat}
@WebService(serviceName = MyService, portName = CustomerServices)
@Stateless(name = MyCustomerService)
public class MyCustomerService {
@EJB
private CoreManager coreManager = null;
public MyCustomerService() {
}
@WebMethod(operationName = createCustomer)
public Customer createCustomer(@WebParam(name = identifier) String
identifier) throws SOAPFaultException {
try {
return this.coreManager.createCustomer(identifier);
} catch (ServiceException e) {
throw this.faultService.createFault(FAULT CODE,
FAULT STRING);
}
}
}
{noformat}
and client catches fault with attributes:
{noformat}
[faultstring]= string(298) java.rmi.RemoteException: The bean
encountered a non-application exception.; nested exception is:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean encountered a
non-application exception.; nested exception i
s: javax.xml.ws.soap.SOAPFaultException: FAULT STRING
[faultcode]= string(11) soap:Server
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3457) Drools BRMS issue using geronimo 2.0.1-jetty6
[ https://issues.apache.org/jira/browse/GERONIMO-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526273 ] Bhagwath Vadyala commented on GERONIMO-3457: works fine with 1.5 jdk... But can we make it work with jdk 1.6? because we are using java script engine functionality of 1.6 in our application. Drools BRMS issue using geronimo 2.0.1-jetty6 - Key: GERONIMO-3457 URL: https://issues.apache.org/jira/browse/GERONIMO-3457 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.1 Environment: geronimo 2.0.1-jetty6 windows drools-jbrms 4.0.1 Reporter: Bhagwath Vadyala Attachments: drools-error-screenshot.doc, geronimo-jetty-server-log.txt We are having an issuing testing drools BRMS 4.0.1 on geronimo 2.0.1 jetty 6 version. It deploys fine but when we open the url http://localhost:8080/drools-jbrms, its not redirecting to correct page. We use the same drools-jbrms war file and deploy on jboss-tomcat it works fine and redirects to the correct page. We posted the issue to JBOSS and here is the response from them. Michael Neale commented on JBRULES-1150: ok the URL in the browser it wrong. Ideally you will put in: http://localhost:8080/drools-jbrms and it *should* redirect to : http://localhost:8080/drools-jbrms/org.drools.brms.JBRMS/JBRMS.html if it doesn't - then it is a bug with how geronimo is redirecting. The index.jsp, which is default, has: % String redirectURL = org.drools.brms.JBRMS/JBRMS.html; response.sendRedirect(redirectURL); % which should work as it does on every other app server tried so far. unfortunately we don't have resources to support every purmutation of app servers/web containers so this will require some experimentation. please let me know how you go. .. Please let me know how to fix this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-196) Maven DependencySet wildcards not working on all platforms (e.g., Mac OS)
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-196. -- Resolution: Fixed Closing since this is now working fine on the Mac Maven DependencySet wildcards not working on all platforms (e.g., Mac OS) - Key: GERONIMODEVTOOLS-196 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-196 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3462) Problem with throwing SOAPFaultException within WebService based on SessionBean
[
https://issues.apache.org/jira/browse/GERONIMO-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526288
]
Tomasz Mazan commented on GERONIMO-3462:
PHP script calls my function
part of wsdl:
{noformat}
wsdl:operation name=createCustomer
wsdl:input message=ns1:createCustomer name=createCustomer
/wsdl:input
wsdl:output message=ns1:createCustomerResponse
name=createCustomerResponse
/wsdl:output
wsdl:fault message=ns1:SOAPFaultException name=SOAPFaultException
/wsdl:fault
/wsdl:operation
xs:complexType name=SOAPFaultException
xs:sequence
xs:element name=faultcode nillable=true type=xs:QName/
xs:element name=faultstring nillable=true type=xs:string/
xs:element name=faultactor nillable=true type=xs:string/
xs:element name=message nillable=true type=xs:string/
/xs:sequence
/xs:complexType
{noformat}
and php code looks like
{noformat}
$soapClient = new
SoapClient(http://localhost:8080/MyApp/MyService?wsdl;, array(exceptions =
true));
$temp = $soapClient - createCustomer(array(identifier =
$argv[1]))-return;
{noformat}
Problem with throwing SOAPFaultException within WebService based on
SessionBean
Key: GERONIMO-3462
URL: https://issues.apache.org/jira/browse/GERONIMO-3462
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: webservices
Affects Versions: 2.0.1
Environment: ApacheCXF as service provider
Reporter: Tomasz Mazan
Assignee: Jarek Gawor
I create SOAPFaultException using code below:
{noformat}
public SOAPFaultException createFault(String errorCode, String
errorString) {
SOAPFault fault = null;
try {
fault = SOAPFactory.newInstance().createFault();
fault.setFaultCode(new QName(foo, bar, abc));
fault.setFaultString(errorString);
fault.setFaultActor(ACTOR);
} catch (SOAPException ex) {
return new SOAPFaultException(null);
}
return new SOAPFaultException(fault);
}
{noformat}
and my WebMethod returns this exception in case internal exception:
{noformat}
@WebService(serviceName = MyService, portName = CustomerServices)
@Stateless(name = MyCustomerService)
public class MyCustomerService {
@EJB
private CoreManager coreManager = null;
public MyCustomerService() {
}
@WebMethod(operationName = createCustomer)
public Customer createCustomer(@WebParam(name = identifier) String
identifier) throws SOAPFaultException {
try {
return this.coreManager.createCustomer(identifier);
} catch (ServiceException e) {
throw this.faultService.createFault(FAULT CODE,
FAULT STRING);
}
}
}
{noformat}
and client catches fault with attributes:
{noformat}
[faultstring]= string(298) java.rmi.RemoteException: The bean
encountered a non-application exception.; nested exception is:
javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean encountered a
non-application exception.; nested exception i
s: javax.xml.ws.soap.SOAPFaultException: FAULT STRING
[faultcode]= string(11) soap:Server
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-175) javamail package is not included in server runtime
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-175. -- Resolution: Fixed Added missing specs to the classpath in revision 574396 to fix the problem. I'll add a new entry to the unstable build site very shortly if anyone would like to verify the fix. Thanks. javamail package is not included in server runtime -- Key: GERONIMODEVTOOLS-175 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-175 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Song Assignee: Tim McConnell Fix For: 2.0 Attachments: GD-175.patch If an application uses javamail, user have to manually add geronimo's javamail jar into build path. Why javamail jar is not included in server runtime by default? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-200) javax.xml.soap not included in geronimo runtime library
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-200. -- Resolution: Fixed Added missing specs to the classpath in revision 574396 to fix the problem. I'll add a new entry to the unstable build site very shortly if anyone would like to verify the fix. Thanks. javax.xml.soap not included in geronimo runtime library --- Key: GERONIMODEVTOOLS-200 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-200 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tomasz Mazan Assignee: Tim McConnell Fix For: 2.0 javax.xml.soap not included in geronimo runtime library by default. User have to import single jar to project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-199) javax.xml.bind is not included in server runtime library
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-199. -- Resolution: Fixed Added missing specs to the classpath in revision 574396 to fix the problem. I'll add a new entry to the unstable build site very shortly if anyone would like to verify the fix. Thanks. javax.xml.bind is not included in server runtime library Key: GERONIMODEVTOOLS-199 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-199 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Tomasz Mazan Assignee: Tim McConnell Fix For: 2.0 JAX-B classes/annotation are not included in default Geronimo's server runtime so user must include single jar to use i.e. XmlElement to annotate classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Ideas on a rc.d kind of directory
Aighty... I'm gonna stop waiting for feedback and implement this stuff for all assemblies. --jason On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote: No...no reasons...move forward ;-) Jeff Jason Dillon wrote: Hey, have you played with the rc.d bits in the assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I whipped up will work for you? Any more comments or suggestions on how that stuff should work? I think this is done, quite powerful and flexible... though to really know for sure we'd need to have a few plugins actually using it to augment the Server's bootstrap configuration a? So... are there any reasons (significant or not) for not moving forward with this? --jason On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote: Jason Dillon wrote: I still think that G could do with a tiny bootstrap JVM to handle all of the required flags and properties that are needed now for the server to opperate properly (and in a platform neutral manner). This could also be used to spawn clones or cluster nodes. As well as handling remote restarts and recovery from JVM crashes. Ok...cool...wanna help? ;-) If we can have a GShell, etc set an env property like JAVA_OPTS, please how an example and I am all game ;-) Jeff IMO this is critical for uber massive enterprise deployments as well as smaller scale cluster management. I also think that GShell would be ideal for the base platform for such a bootstrap JVM. I think it should be realativly easy to setup a POC if folks are interested. --jason P.S. Typed on my iPhone. Still not quite as fast as my blackberry... But I dropped in beer at the Giants/Doggers game. Ooops ;-) On Jul 14, 2007, at 6:41 AM, Jeff Genender [EMAIL PROTECTED] wrote: Donald Woods wrote: Is this a scenario that would be better handled by the gshell code in sandbox or some daemon code that also handles the multiple server instance support? Thought here, would be gshell could read a standard Java properties file for JVM args and then launch the server with them. As long as one JVM launches, the other (ie. gshell or groovy can start another instance of a JVM) then this is doable. Otherwise, this won't work...with my Terracotta example being a reason. In my eyes, scripts are a no-go, unless you can make them platform neutral and not require users to install a third-party solution like Perl (on Windows) to make it work. We already ship sh and bat code...why would this be a no-go? If this is the case, then we shouldn't be shipping startup scripts in bat and sh format. -Donald Jeff Genender wrote: Hi, As we move forward and we integrate with more and more 3rd party products, we will need the ability to be able to change an environment variable through a plugin, or add a commandline JAVA_OPTS, etc. Currently our startup scripts call the setjavaenv.sh to set environment properties. It would really be nice to have the ability to have a scripts directory, where all of the scripts get executed before Geronimo is launched. Why do we want this? As we grow in our plugins, they will need to set environment or java options set before running G. They may also have a need to start or run other outside processes that are not a part of G. It would be great to allow plugins to install an rc script that gets executed to do activities before and perhaps after G is run? I would propose we create a scripts directory under bin or under var that could be similar to init.d, and have it called with start/stop, etc. This way plugins can install specific scripts in these directories for execution. Thoughts? Jeff
Re: Ideas on a rc.d kind of directory
Jason Dillon wrote: Aighty... I'm gonna stop waiting for feedback and implement this stuff for all assemblies. U...what am I...chopped liver? ;-) --jason On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote: No...no reasons...move forward ;-) Jeff Jason Dillon wrote: Hey, have you played with the rc.d bits in the assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I whipped up will work for you? Any more comments or suggestions on how that stuff should work? I think this is done, quite powerful and flexible... though to really know for sure we'd need to have a few plugins actually using it to augment the Server's bootstrap configuration a? So... are there any reasons (significant or not) for not moving forward with this? --jason On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote: Jason Dillon wrote: I still think that G could do with a tiny bootstrap JVM to handle all of the required flags and properties that are needed now for the server to opperate properly (and in a platform neutral manner). This could also be used to spawn clones or cluster nodes. As well as handling remote restarts and recovery from JVM crashes. Ok...cool...wanna help? ;-) If we can have a GShell, etc set an env property like JAVA_OPTS, please how an example and I am all game ;-) Jeff IMO this is critical for uber massive enterprise deployments as well as smaller scale cluster management. I also think that GShell would be ideal for the base platform for such a bootstrap JVM. I think it should be realativly easy to setup a POC if folks are interested. --jason P.S. Typed on my iPhone. Still not quite as fast as my blackberry... But I dropped in beer at the Giants/Doggers game. Ooops ;-) On Jul 14, 2007, at 6:41 AM, Jeff Genender [EMAIL PROTECTED] wrote: Donald Woods wrote: Is this a scenario that would be better handled by the gshell code in sandbox or some daemon code that also handles the multiple server instance support? Thought here, would be gshell could read a standard Java properties file for JVM args and then launch the server with them. As long as one JVM launches, the other (ie. gshell or groovy can start another instance of a JVM) then this is doable. Otherwise, this won't work...with my Terracotta example being a reason. In my eyes, scripts are a no-go, unless you can make them platform neutral and not require users to install a third-party solution like Perl (on Windows) to make it work. We already ship sh and bat code...why would this be a no-go? If this is the case, then we shouldn't be shipping startup scripts in bat and sh format. -Donald Jeff Genender wrote: Hi, As we move forward and we integrate with more and more 3rd party products, we will need the ability to be able to change an environment variable through a plugin, or add a commandline JAVA_OPTS, etc. Currently our startup scripts call the setjavaenv.sh to set environment properties. It would really be nice to have the ability to have a scripts directory, where all of the scripts get executed before Geronimo is launched. Why do we want this? As we grow in our plugins, they will need to set environment or java options set before running G. They may also have a need to start or run other outside processes that are not a part of G. It would be great to allow plugins to install an rc script that gets executed to do activities before and perhaps after G is run? I would propose we create a scripts directory under bin or under var that could be similar to init.d, and have it called with start/stop, etc. This way plugins can install specific scripts in these directories for execution. Thoughts? Jeff
Re: Ideas on a rc.d kind of directory
I meant stop waiting for _more_ feedback :-P So far its all been good, but its a bigish change so I wanted to wait for a bit before I did it. I've also been sexying up gshell... :-P --jason On Sep 10, 2007, at 5:54 PM, Jeff Genender wrote: Jason Dillon wrote: Aighty... I'm gonna stop waiting for feedback and implement this stuff for all assemblies. U...what am I...chopped liver? ;-) --jason On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote: No...no reasons...move forward ;-) Jeff Jason Dillon wrote: Hey, have you played with the rc.d bits in the assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I whipped up will work for you? Any more comments or suggestions on how that stuff should work? I think this is done, quite powerful and flexible... though to really know for sure we'd need to have a few plugins actually using it to augment the Server's bootstrap configuration a? So... are there any reasons (significant or not) for not moving forward with this? --jason On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote: Jason Dillon wrote: I still think that G could do with a tiny bootstrap JVM to handle all of the required flags and properties that are needed now for the server to opperate properly (and in a platform neutral manner). This could also be used to spawn clones or cluster nodes. As well as handling remote restarts and recovery from JVM crashes. Ok...cool...wanna help? ;-) If we can have a GShell, etc set an env property like JAVA_OPTS, please how an example and I am all game ;-) Jeff IMO this is critical for uber massive enterprise deployments as well as smaller scale cluster management. I also think that GShell would be ideal for the base platform for such a bootstrap JVM. I think it should be realativly easy to setup a POC if folks are interested. --jason P.S. Typed on my iPhone. Still not quite as fast as my blackberry... But I dropped in beer at the Giants/Doggers game. Ooops ;-) On Jul 14, 2007, at 6:41 AM, Jeff Genender [EMAIL PROTECTED] wrote: Donald Woods wrote: Is this a scenario that would be better handled by the gshell code in sandbox or some daemon code that also handles the multiple server instance support? Thought here, would be gshell could read a standard Java properties file for JVM args and then launch the server with them. As long as one JVM launches, the other (ie. gshell or groovy can start another instance of a JVM) then this is doable. Otherwise, this won't work...with my Terracotta example being a reason. In my eyes, scripts are a no-go, unless you can make them platform neutral and not require users to install a third-party solution like Perl (on Windows) to make it work. We already ship sh and bat code...why would this be a no-go? If this is the case, then we shouldn't be shipping startup scripts in bat and sh format. -Donald Jeff Genender wrote: Hi, As we move forward and we integrate with more and more 3rd party products, we will need the ability to be able to change an environment variable through a plugin, or add a commandline JAVA_OPTS, etc. Currently our startup scripts call the setjavaenv.sh to set environment properties. It would really be nice to have the ability to have a scripts directory, where all of the scripts get executed before Geronimo is launched. Why do we want this? As we grow in our plugins, they will need to set environment or java options set before running G. They may also have a need to start or run other outside processes that are not a part of G. It would be great to allow plugins to install an rc script that gets executed to do activities before and perhaps after G is run? I would propose we create a scripts directory under bin or under var that could be similar to init.d, and have it called with start/stop, etc. This way plugins can install specific scripts in these directories for execution. Thoughts? Jeff
Re: Ideas on a rc.d kind of directory
Don't make me open up a can of whoop-ass now... --jason On Sep 10, 2007, at 6:17 PM, Jeff Genender wrote: Hehehe...Jason...messing with you is like going to Disneyland...all fun ;-) Dude...you rock :-) Keep up the awesome work! Jefff Jason Dillon wrote: I meant stop waiting for _more_ feedback :-P So far its all been good, but its a bigish change so I wanted to wait for a bit before I did it. I've also been sexying up gshell... :-P --jason On Sep 10, 2007, at 5:54 PM, Jeff Genender wrote: Jason Dillon wrote: Aighty... I'm gonna stop waiting for feedback and implement this stuff for all assemblies. U...what am I...chopped liver? ;-) --jason On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote: No...no reasons...move forward ;-) Jeff Jason Dillon wrote: Hey, have you played with the rc.d bits in the assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I whipped up will work for you? Any more comments or suggestions on how that stuff should work? I think this is done, quite powerful and flexible... though to really know for sure we'd need to have a few plugins actually using it to augment the Server's bootstrap configuration a? So... are there any reasons (significant or not) for not moving forward with this? --jason On Jul 16, 2007, at 6:09 AM, Jeff Genender wrote: Jason Dillon wrote: I still think that G could do with a tiny bootstrap JVM to handle all of the required flags and properties that are needed now for the server to opperate properly (and in a platform neutral manner). This could also be used to spawn clones or cluster nodes. As well as handling remote restarts and recovery from JVM crashes. Ok...cool...wanna help? ;-) If we can have a GShell, etc set an env property like JAVA_OPTS, please how an example and I am all game ;-) Jeff IMO this is critical for uber massive enterprise deployments as well as smaller scale cluster management. I also think that GShell would be ideal for the base platform for such a bootstrap JVM. I think it should be realativly easy to setup a POC if folks are interested. --jason P.S. Typed on my iPhone. Still not quite as fast as my blackberry... But I dropped in beer at the Giants/Doggers game. Ooops ;-) On Jul 14, 2007, at 6:41 AM, Jeff Genender [EMAIL PROTECTED] wrote: Donald Woods wrote: Is this a scenario that would be better handled by the gshell code in sandbox or some daemon code that also handles the multiple server instance support? Thought here, would be gshell could read a standard Java properties file for JVM args and then launch the server with them. As long as one JVM launches, the other (ie. gshell or groovy can start another instance of a JVM) then this is doable. Otherwise, this won't work...with my Terracotta example being a reason. In my eyes, scripts are a no-go, unless you can make them platform neutral and not require users to install a third-party solution like Perl (on Windows) to make it work. We already ship sh and bat code...why would this be a no- go? If this is the case, then we shouldn't be shipping startup scripts in bat and sh format. -Donald Jeff Genender wrote: Hi, As we move forward and we integrate with more and more 3rd party products, we will need the ability to be able to change an environment variable through a plugin, or add a commandline JAVA_OPTS, etc. Currently our startup scripts call the setjavaenv.sh to set environment properties. It would really be nice to have the ability to have a scripts directory, where all of the scripts get executed before Geronimo is launched. Why do we want this? As we grow in our plugins, they will need to set environment or java options set before running G. They may also have a need to start or run other outside processes that are not a part of G. It would be great to allow plugins to install an rc script that gets executed to do activities before and perhaps after G is run? I would propose we create a scripts directory under bin or under var that could be similar to init.d, and have it called with start/stop, etc. This way plugins can install specific scripts in these directories for execution. Thoughts? Jeff
[jira] Commented: (GERONIMO-3457) Drools BRMS issue using geronimo 2.0.1-jetty6
[ https://issues.apache.org/jira/browse/GERONIMO-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526331 ] Kevan Miller commented on GERONIMO-3457: Whoa... Nice Donald... Bhagwath, definitely worth noting in the Environment section of a Jira, next time... I did see some Jetty startup errors on a Mac OS X 1.6 JRE (https://issues.apache.org/jira/browse/GERONIMO-3454). This is looking like some xalan/xerces library mismatch... Are you on the latest service release of 1.6? Drools BRMS issue using geronimo 2.0.1-jetty6 - Key: GERONIMO-3457 URL: https://issues.apache.org/jira/browse/GERONIMO-3457 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.1 Environment: geronimo 2.0.1-jetty6 windows drools-jbrms 4.0.1 Reporter: Bhagwath Vadyala Attachments: drools-error-screenshot.doc, geronimo-jetty-server-log.txt We are having an issuing testing drools BRMS 4.0.1 on geronimo 2.0.1 jetty 6 version. It deploys fine but when we open the url http://localhost:8080/drools-jbrms, its not redirecting to correct page. We use the same drools-jbrms war file and deploy on jboss-tomcat it works fine and redirects to the correct page. We posted the issue to JBOSS and here is the response from them. Michael Neale commented on JBRULES-1150: ok the URL in the browser it wrong. Ideally you will put in: http://localhost:8080/drools-jbrms and it *should* redirect to : http://localhost:8080/drools-jbrms/org.drools.brms.JBRMS/JBRMS.html if it doesn't - then it is a bug with how geronimo is redirecting. The index.jsp, which is default, has: % String redirectURL = org.drools.brms.JBRMS/JBRMS.html; response.sendRedirect(redirectURL); % which should work as it does on every other app server tried so far. unfortunately we don't have resources to support every purmutation of app servers/web containers so this will require some experimentation. please let me know how you go. .. Please let me know how to fix this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3466) car-maven-plugin can not generate server plugin which includes EJB
car-maven-plugin can not generate server plugin which includes EJB
--
Key: GERONIMO-3466
URL: https://issues.apache.org/jira/browse/GERONIMO-3466
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: car-maven-plugin
Affects Versions: 2.0.1
Reporter: YunFeng Ma
Fix For: 2.0.x
openejb-deployer configuration depends on openejb configuration, and openejb
configuration depends on j2ee-server configuration. That means car-maven-plugin
has to start all the depended configurations, not only the openejb-deployer
configuration. This caused the following error.
{code}
[INFO] Scanning for projects...
[INFO] -
---
[INFO] Building daytrader-derby-tomcat
[INFO]task-segment: [install]
[INFO] -
---
[INFO] [dependency:unpack {execution: unpack-distribution}]
[INFO] Configured Artifact: org.apache.geronimo.daytrader:daytrader-ear:2.0:ear
[INFO] daytrader-ear-2.0.ear already unpacked.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: F:\WASCE\samples_v2\plugins\daytrader-derby-tomcat\target\plan
\plan.xml
log4j:WARN No appenders could be found for logger (org.codehaus.mojo.pluginsuppo
rt.logging.Logging).
log4j:WARN Please initialize the log4j system properly.
[INFO] [car:package]
[INFO] Packaging module configuration: F:\WASCE\samples_v2\plugins\daytrader-der
by-tomcat\target\plan\plan.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] start of org.apache.geronimo.configs/openejb-deployer/2.0.1/car failed
Configuration org.apache.geronimo.configs/j2ee-system/2.0.1/car failed to start
due to the following reasons:
The service ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=GBean,name=ServerInfo did not start because Could not determine geronimo
installation directory
The service ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=Repository,name=Repository did not start because org.apache.geronimo.conf
igs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/
2.0.1/car,j2eeType=GBean,name=ServerInfo did not start.
The service ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=ConfigurationStore,name=Local did not start because org.apache.geronimo.c
onfigs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-syst
em/2.0.1/car,j2eeType=Repository,name=Repository did not start.
The service ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=AttributeStore,name=AttributeManager did not start because org.apache.ger
onimo.configs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2
ee-system/2.0.1/car,j2eeType=GBean,name=ServerInfo did not start.
The service ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=ArtifactResolver,name=ArtifactResolver did not start because org.apache.g
eronimo.configs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/
j2ee-system/2.0.1/car,j2eeType=GBean,name=ServerInfo did not start.
The service ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=ConfigurationManager,name=ConfigurationManager did not start because the
following dependent services did not start: [org.apache.geronimo.configs/j2ee-sy
stem/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j
2eeType=ArtifactResolver,name=ArtifactResolver, org.apache.geronimo.configs/j2ee
-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/ca
r,j2eeType=AttributeStore,name=AttributeManager]
The service ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=SystemLog,name=Logger did not start because org.apache.geronimo.configs/j
2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1
/car,j2eeType=GBean,name=ServerInfo did not start.
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: start of org.apache.gero
nimo.configs/openejb-deployer/2.0.1/car failed
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:564)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:459)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
Looking for a consultant
Hello, My name is Wayne Rasmuss. I'm looking for a cosultant with intimate knowledge of Geronimo. To answer questions, make reccomendations and some light development. Any reccomendations? Wayne Rasmuss Popstar Networks -- View this message in context: http://www.nabble.com/Looking-for-a-consultant-tf4419938s134.html#a12606900 Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526353 ] Vamsavardhana Reddy commented on GERONIMO-2964: --- I think we should come up with a test case to see if this patch really comes in the way of compatibility with plugins built for G 2.0.1. Donald, do you have a test scenario in mind? Cannot specify the Tomcat work directory for a web application -- Key: GERONIMO-2964 URL: https://issues.apache.org/jira/browse/GERONIMO-2964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 2.0-M5 Reporter: Aman Nanner Priority: Minor Fix For: 1.2, 2.1 Attachments: g2964.war, GERONIMO-2964-combined.patch, GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch In Tomcat, a work directory can be specified for a web application in a WEB-INF/context.xml file. The GeronimoStandardContext does not permit the user to specify a work directory, and so the work directory defaults to var/catalina/work/web-app. I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to permit the user to optionally specify a work directory. This work directory is then propagated into the TomcatContext. I've tested this and it seems to work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
