Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback)
There are several mechasinsm the security manager uses to compare credentials. Implement Comparable if you want to control the comparision. Look at the JaasSecurityManager code for the comparison preferences. Scott StarkChief Technology OfficerJBoss Group, LLC - Original Message - From: Jason Essington To: [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 8:43 AM Subject: [JBoss-dev] authenticating using a non-text credential (ObjectCallback) I am trying to allow a login using an X509 Certificate as a credential. My login module uses an ObjectCallback to retrieve the certificate.All is fine and dandy if I do something like this:String domain = authMgr.getSecurityDomain();ObjectCallbackHandler och = new ObjectCallbackHandler(cert); // use my own callback handlerLoginContext lc = new LoginContext(domain, och);lc.login();but further on down the road (mere milliseconds later actually) when the JaasSecurityManager attempts to call its isValid(Principal, Object) method, the SecurityAssiciationHandler (used in the private defaultLogin() method) chokes on the callback.I am storing the credential (certificate) in SecurityAssociation, which allows any object to be held as a credential. Do I need to extend the JaasSecurityManager (actually JaasSecurityDomain) to be able to properly verify ( isValid() ) this type of credential, or am I making things more difficult than they should be?Thanks-jason
Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback)
Right, so the only place comparisons are made is in the validateCache() method. Does the initial login (from the code below) populate the domainCache with CacheInfo for the comparison, or does it need to be done some other way. If the cache is nonexistant or expired login falls through to the defaultLogin method which will cause unsupported callback exceptions. thanks -jason There are several mechasinsm the security manager uses to compare credentials. Implement Comparable if you want to control the comparision. Look at the JaasSecurityManager code for the comparison preferences. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Essington To: [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 8:43 AM Subject: [JBoss-dev] authenticating using a non-text credential (ObjectCallback) I am trying to allow a login using an X509 Certificate as a credential. My login module uses an ObjectCallback to retrieve the certificate. All is fine and dandy if I do something like this: String domain = authMgr.getSecurityDomain(); ObjectCallbackHandler och = new ObjectCallbackHandler(cert); // use my own callback handler LoginContext lc = new LoginContext(domain, och); lc.login(); but further on down the road (mere milliseconds later actually) when the JaasSecurityManager attempts to call its isValid(Principal, Object) method, the SecurityAssiciationHandler (used in the private defaultLogin() method) chokes on the callback. I am storing the credential (certificate) in SecurityAssociation, which allows any object to be held as a credential. Do I need to extend the JaasSecurityManager (actually JaasSecurityDomain) to be able to properly verify ( isValid() ) this type of credential, or am I making things more difficult than they should be? Thanks -jason
Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback)
Yes, the successful login populates the cache with the authentication info. After that, only validateCache needs to be able to compare the opaque credentials against the cache value. If there is no cache the login module is called to authenticate the credentials and this has to understand what the credentials are and be able to interact with the handler. The JaasSecurityManager does not care about the credentials other than needing to be able to compare the raw cached credentials against the invocation credentials. As long as the credential object implements the Comparable interface this can be done and is the first check made. If the credential implements equals things will also work. Scott StarkChief Technology OfficerJBoss Group, LLC - Original Message - From: Jason Essington To: [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 4:20 PM Subject: Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback) Right, so the only place comparisons are made is in the validateCache() method. Does the initial login (from the code below) populate the domainCache with CacheInfo for the comparison, or does it need to be done some other way. If the cache is nonexistant or expired login falls through to the defaultLogin method which will cause unsupported callback exceptions.thanks-jason
[JBoss-dev] [ jboss-Bugs-639102 ] JCA: ra.xml config-property ignored
Bugs item #639102, was opened at 2002-11-15 21:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=639102group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Don Lind (dlind) Assigned to: David Jencks (d_jencks) Summary: JCA: ra.xml config-property ignored Initial Comment: My OS is Windows 2000 with latest service packs. JDK is 1.4.0_01-b03 with j2sdkee 1.3.1 Problem happens on JBoss 4.0.2 and 4.0.4. My JCA Adapter has an ra.xml file with several config- property values specified. When I deploy under the Sun Reference Implementation J2EE server, during initialization, my adapter gets called by the app server with each specified config-property. But, when I deploy under JBoss, JBoss does not make those calls into my adapter. If I copy the config- property information into my adapter's eProcessJCA- service.xml file, JBoss then makes the calls into my adapter as it's being initialized. So, JBoss *can* make the calls into my adapter. But, it doesn't make the calls based on info in the ra.xml file. And, I know JBoss is seeing the info in the ra.xml file because it shows up in the mbean with the mbean description of Description of a deployed Resource Adapter. I'd expect that if there are config-property entries in the ra.xml, that JBoss would call my adapter with those values (and that the *-service.xml config-property values would override anything in the ra.xml). Below is my ra.xml. ?xml version=1.0 encoding=UTF-8? !DOCTYPE connector PUBLIC '-//Sun Microsystems, Inc.//DTD Connector 1.0//EN' 'http://java.sun.com/dtd/connector_1_0.dtd' connector display-nameeProcess Resource Adapter/display- name descriptioneProcess JCA Connector/description vendor-nameFileNET Corporation/vendor-name spec-version1.0/spec-version eis-typeeProcess/eis-type version1.0/version resourceadapter managedconnectionfactory- classfilenet.vw.jca.FNePManagedConnectionFactory/ managedconnectionfactory-class connectionfactory- interfacejavax.resource.cci.ConnectionFactory/connec tionfactory-interface connectionfactory-impl- classfilenet.vw.jca.FNePConnectionFactory/connectio nfactory-impl-class connection- interfacejavax.resource.cci.Connection/connection- interface connection-impl- classfilenet.vw.jca.FNePConnection/connection-impl- class transaction-supportXATransaction/transaction- support config-property config-property-nameServerName/config- property-name config-property-typejava.lang.String/config- property-type config-property-valueDon/config-property- value /config-property config-property descriptionThe URL to the eProcess Router/description config-property-nameConnectionURL/config- property-name config-property-typejava.lang.String/config- property-type config-property-valuevwrouter/config-property- value /config-property config-property descriptionThe eProcess Router Port/description config-property-namePortNumber/config- property-name config-property-typejava.lang.String/config- property-type config-property-value1099/config-property- value /config-property config-property config-property-nameUserName/config- property-name config-property-typejava.lang.String/config- property-type config-property-valueSysAdmin/config- property-value /config-property config-property config-property-namePassword/config- property-name config-property-typejava.lang.String/config- property-type config-property-valueSysAdmin/config- property-value /config-property authentication-mechanism authentication-mechanism- typeBasicPassword/authentication-mechanism-type credential- interfacejavax.resource.security.PasswordCredential/c redential-interface /authentication-mechanism reauthentication-supportfalse/reauthentication- support /resourceadapter /connector -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=639102group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-634362 ] Failure if EntityBean overrides hashCode
Bugs item #634362, was opened at 2002-11-06 10:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=634362group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 7 Submitted By: Michael Lipp (mlipp) Assigned to: David Jencks (d_jencks) Summary: Failure if EntityBean overrides hashCode Initial Comment: This is a follow on to #595738 which has not been fixed properly. The CachedConnectionManager uses an entity beans equals and hashCode method to manage EJB containers. This fails if the EJB itself overrides equals/hashCode (see #595738 for a detailed description). The proper solution to the problem are collection/map implementations that use == instead of equals and System.identityHashCode instead of hashCode. The class IdentityWrapper which now exists in 3.0.4 does not solve the problem. It still calls hashCode on the EJB and (as explained in the previous bug report) a an EJB's hashCode implementation may fail if the EJB is in the pooled state. Worse, the current implementation actually disables connection caching. As every object is wrapped with a new IdentityWrapper (key = new IdentityWrapper(rawKey)), the stack.contains(key) will *always* fail. -- Comment By: David Jencks (d_jencks) Date: 2002-11-21 06:32 Message: Logged In: YES user_id=60525 I agree that using System.identityHashCode is better than using the underlying object's hashcode ( and I will change it shortly), but I'm not at all convinced that the current implementation is broken. In particular, since the wrapper's equal is based on == for the underlying object, the stack.contains(key) will work properly. If you disagree please provide code that demonstrates your claim. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=634362group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-626280 ] ServiceController warning
Bugs item #626280, was opened at 2002-10-21 10:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=626280group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: marco dubbeld (dubbeld) Assigned to: David Jencks (d_jencks) Summary: ServiceController warning Initial Comment: Pure MBeans implementing DynamicMBean and MBeanRegistration will get warning form ServiceController: [WARN, ServiceController] does not implement any Service methods This could be level INFO and indicating it's relative to the jboss specific life-cycle using Service. -- Comment By: David Jencks (d_jencks) Date: 2002-11-21 06:38 Message: Logged In: YES user_id=60525 I think removing the warning entirely is the best plan. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=626280group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-623108 ] Can't view XaTxCM MBean in JMX Console
Bugs item #623108, was opened at 2002-10-14 16:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=623108group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Benjamin Geer (beroul) Assigned to: David Jencks (d_jencks) Summary: Can't view XaTxCM MBean in JMX Console Initial Comment: In JBoss 3.2 beta, I've started the server with run -c all, and I'm trying to inspect the MBean called service=XaTxCM,name=jmsra in the JMX console (http://localhost:8080/jmx-console/). When I click on the link for that MBean, I get an error page that says HTTP ERROR: 500 Internal Server Error. The JBoss log says: 17:08:26,993 WARN [jbossweb] WARNING: Exception for /jmx-console/HtmlAdaptor?ac tion=inspectMBeanname=jboss.jca%3Aservice%3DXaTxCM%2Cname%3Djmsra java.lang.reflect.UndeclaredThrowableException at $Proxy31.toString(Unknown Source) at org.jboss.jmx.adaptor.control.AttrResultInfo.getAsText(AttrResultInfo .java:42) at org.apache.jsp.inspectMBean_jsp._jspService(inspectMBean_jsp.java:167 ) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper .java:202) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:2 89) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:362 ) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java:284) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:216) at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:151) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.inspectMBean(HtmlAdapto rServlet.java:113) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdap torServlet.java:73) at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doGet(HtmlAdaptorServle t.java:54) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:362 ) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicati onHandler.java:284) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:5 65) at org.mortbay.http.HttpContext.handle(HttpContext.java:1664) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplication Context.java:544) at org.mortbay.http.HttpContext.handle(HttpContext.java:1614) at org.mortbay.http.HttpServer.service(HttpServer.java:875) at org.jboss.jetty.Jetty.service(Jetty.java:531) at org.mortbay.http.HttpConnection.service(HttpConnection.java:785) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:935) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:802) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java: 200) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:294) at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:743) at java.lang.Thread.run(Thread.java:536) Caused by: java.lang.NoSuchMethodException: Unable to locate method for: toStrin g() at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:288) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) ... 33 more -- Comment By: David Jencks (d_jencks) Date: 2002-11-21 06:42 Message: Logged In: YES user_id=60525 This is caused by the mbean proxy trying to forward a toString method call which is not implemented in the mbean interface. I'll backport the fix from 4.0 -- Comment By: prabhakar chaganti (prabhakar) Date: 2002-11-03 03:55 Message: Logged In: YES user_id=38193 This works fine with jboss-head from today. -prabhakar -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=623108group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-621692 ] NoTxConnection -- Periodic SQLExceptions
Bugs item #621692, was opened at 2002-10-11 03:27
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=621692group_id=22866
Category: JBossCX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: David Jencks (d_jencks)
Summary: NoTxConnection -- Periodic SQLExceptions
Initial Comment:
Regarding the NoTxConnection manager to work...
I was wondering if there was a way to use a managed
connection from an MBean, for example, (look at the
billing-service.xml file attached), I want to use
the 'billing' datasource to log records to the database
using an MBean, while also using it from
a MessageDrivenBean. Periodically I get exceptions,
however:
(Note that the SQL connection was obtained
during the MBean initialization, and this MBean
is being called by a MDB using JNDI.)
java.sql.SQLException: Connection handle is not currently associated with a
ManagedConnection
at
org.jboss.resource.adapter.jdbc.local.LocalConnection.checkStatus(LocalConnection.java:774)
at
org.jboss.resource.adapter.jdbc.local.LocalConnection.checkTransaction(LocalConnection.java:755)
at
org.jboss.resource.adapter.jdbc.local.LocalStatement.checkTransaction(LocalStatement.java:771)
at
org.jboss.resource.adapter.jdbc.local.LocalPreparedStatement.executeUpdate(LocalPreparedStatement.java:305)
at com.proteusmobile.oamp.mdr.MdrDBAppender.logDB(MdrDBAppender.java:200)
... 31 more
Is this a bug or am I configuring things incorrectly?
This is with Oracle 9.2, JBoss 3.0.1, on Java 1.4
on Linux.
--
Comment By: Elias Ross (genman)
Date: 2002-10-11 03:56
Message:
Logged In: YES
user_id=556458
Sorry for the multiple postings (sourceforge.net
timed out my browser several times.)
I've noticed that using Java 1.3.1 the periodic
problem of mine goes away.
I suspect it's probably an issue of concurrency.
I'm pumping out messages like at the rate of 50-100/second.
--
Comment By: Elias Ross (genman)
Date: 2002-10-11 03:56
Message:
Logged In: YES
user_id=556458
Sorry for the multiple postings (sourceforge.net
timed out my browser several times.)
I've noticed that using Java 1.3.1 the periodic
problem of mine goes away.
I suspect it's probably an issue of concurrency.
I'm pumping out messages like at the rate of 50-100/second.
--
Comment By: Elias Ross (genman)
Date: 2002-10-11 03:32
Message:
Logged In: YES
user_id=556458
Forgot to submit the XML file.
The MBean in start service looks something like this:
public class {
Connection con;
public void startService() throws Exception {
con = new InitialContext().lookup(java:/billing/ds);
}
public void billSomething() throws Exception {
PrepareStatement ps = con.prepareStatement(insert ...);
ps.executeUpdate();
}
}
--
Comment By: Elias Ross (genman)
Date: 2002-10-11 03:32
Message:
Logged In: YES
user_id=556458
Forgot to submit the XML file.
The MBean in start service looks something like this:
public class {
Connection con;
public void startService() throws Exception {
con = new InitialContext().lookup(java:/billing/ds);
}
public void billSomething() throws Exception {
PrepareStatement ps = con.prepareStatement(insert ...);
ps.executeUpdate();
}
}
--
Comment By: Elias Ross (genman)
Date: 2002-10-11 03:32
Message:
Logged In: YES
user_id=556458
Forgot to submit the XML file.
The MBean in start service looks something like this:
public class {
Connection con;
public void startService() throws Exception {
con = new InitialContext().lookup(java:/billing/ds);
}
public void billSomething() throws Exception {
PrepareStatement ps = con.prepareStatement(insert ...);
ps.executeUpdate();
}
}
--
Comment By: Elias Ross (genman)
Date: 2002-10-11 03:32
Message:
Logged In: YES
user_id=556458
Forgot to submit the XML file.
The MBean in start service looks something like this:
public class {
Connection con;
public void startService() throws Exception {
con = new InitialContext().lookup(java:/billing/ds);
}
public void billSomething() throws Exception {
PrepareStatement ps = con.prepareStatement(insert ...);
ps.executeUpdate();
}
}
--
Comment By: Elias Ross (genman)
Date: 2002-10-11 03:31
Message:
Logged In: YES
user_id=556458
Forgot to submit the XML file.
The MBean in start service looks something like this:
public class {
Connection con;
public void startService() throws Exception {
con = new InitialContext().lookup(java:/billing/ds);
}
public void
[JBoss-dev] [ jboss-Bugs-640991 ] field names are not quoted
Bugs item #640991, was opened at 2002-11-20 00:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=640991group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Adam Heath (doogie) Assigned to: Dain Sundstrom (dsundstrom) Summary: field names are not quoted Initial Comment: Certain databases have certain keywords reserved. To prevent this, *all* table names, and *all* column names must be quoted. To observe this very broken behaviour, do the following: 1. Download ITracker(www.sf.net/projects/itracker, version 1.4.0) 2. Convert the ear to an unpacked form(unzip, rename, unpack, etc) 3. Change standardjbosscmp-jdbc.xml to use a type mapping of PostgreSQL. 4. Disable(or remove) server/default/deploy/hsqldb-service.xml 5. Add postgresql.jar to server/default/deploy 6. Add postgresql-service.xml to server/default/deploy 7. Add itracker.ear to server/default/deploy 8. bin/run.sh Postgres will have an error parsing the generated sql, because this code uses a CMR of 'user', which is a reserved word. If I cut and paste the generated CREATE TABLE command into psql, and use to quote user, it will eventually deploy. But then, later on, it'll fail as it tries to query and set the values. Since JBoss can have no way of knowing this kind of information, *all* such non-sql keywords should be quoted. This bug first discovered on 3.0.1, and I just downloaded a brand new 3.0.4, to verify it's existance(which is how I knew the exact steps to duplicate it). I'm running postgres 7.2.1. Debian unstable(sid), i386. -- Comment By: Kevin Conner (kevinconner) Date: 2002-11-20 09:17 Message: Logged In: YES user_id=598569 Hiya Dain. I have already got a patch for the 3.0.2 source that fixes this. I've been meaning to post it for a while but things have gotten very hectic here :-), personally and professionally. I'm going to have a look at moving my patches to the 3.0.4 source this weekend and will post something at the beginning of next week. BTW I had to jump through a lot of hoops to get the metadata consistent, would you expect this? Kev -- Comment By: Adam Heath (doogie) Date: 2002-11-20 07:01 Message: Logged In: YES user_id=9692 Well, I still consider this a bug, that should remain open. 'user' is a very common name, both in database implementations and in user code. If you can tell me that the only place sql is generated is in the compiler classes, then I can have a go at adding code to do this escaping. My question then becomes how best to export this feature into the configuration space. Should it be part of standardjbosscmp-jdbc.xml, globally, or inside each ejb, per field/entity, or a combination of all? As to making the sql harder to read, why is that a problem? JBoss is supposed to hide all this database complexity, no one should ever need to read the sql, *ever*. If everything works, then all a user/developer needs to be concerned with is calilng methods on entities. This kind of bug exposes problems with the underlying database, which is one of the main driving forces j2ee container systems are supposed to hide. The note about case sensitvity is a valid point, however. It's such a shame sql is so shitty in this regard. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-20 06:26 Message: Logged In: YES user_id=251431 Adam please read the feature list before posting. This has been a know issue for a long time (see feature request 555315). The reason I didn't code it that way, was I personally would never use any name that had to be quoted in a database. Anyway, it is not true that all databases support quoted identifiers. We actually need to check the database metadata first. Also I think we should not use quotes unless absolutely necessary as it makes the SQL harder to read. -dain -- Comment By: Jeremy Boynes (jboynes) Date: 2002-11-20 06:07 Message: Logged In: YES user_id=378919 Another consequence of quoting is to make name matching case sensitive (normally it is case blind). As least that what SQL-92 says, not all databases do it. I believe this would lead to confusion as JBoss would be using case-sensitive quoted identifiers and most other applications and tools would not. Quoting some of the time (e.g. only keywords) would be even more confusing. A simple workaround might be to quote the identifier in jbosscmp-jdbc.xml (e.g. table-nameuser/table-name or column-nameuser/column-name ) as I believe this is passed directly into the SQL text. Of course, you could also set a table/column name here that didn't conflict and save everyone some confusion.
Re: [JBoss-dev] Unneccessary Jetty error in 3.2
My mistake - I've got too used to only running 'all'. Since I see that you have now released the new beta, what is the status of this ? Have you included JavaGroups in default ? Or is the Exception still there ? Jules Scott M Stark wrote: This error is showing up when running the default config of the 3.2 branch due to the JavaGroups jar not being available in this config. This should not be printed as an error. 10:36:14,338 ERROR [jbossweb] problem configuring Jetty: java.lang.ClassNotFoundException: Unexpected error during load of: org.mortbay.j2ee.session.JGStore, msg=org/javagroups/MessageListener at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:185) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at org.mortbay.util.Loader.loadClass(Loader.java:36) at org.mortbay.xml.XmlConfiguration.nodeClass(XmlConfiguration.java:198) at org.mortbay.xml.XmlConfiguration.newObj(XmlConfiguration.java:520) at org.mortbay.xml.XmlConfiguration.itemValue(XmlConfiguration.java:792) at org.mortbay.xml.XmlConfiguration.value(XmlConfiguration.java:698) at org.mortbay.xml.XmlConfiguration.set(XmlConfiguration.java:259) at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:227) at org.mortbay.xml.XmlConfiguration.newObj(XmlConfiguration.java:568) at org.mortbay.xml.XmlConfiguration.itemValue(XmlConfiguration.java:792) at org.mortbay.xml.XmlConfiguration.value(XmlConfiguration.java:698) at org.mortbay.xml.XmlConfiguration.set(XmlConfiguration.java:259) at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:227) at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:163) at org.jboss.jetty.Jetty.setXMLConfiguration(Jetty.java:305) at org.jboss.jetty.Jetty.setConfigurationElement(Jetty.java:278) at org.jboss.jetty.JettyService.createService(JettyService.java:165) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:168) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:962) at $Proxy9.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:311) at org.jboss.system.ServiceController.create(ServiceController.java:244) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy5.create(Unknown Source) Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-636693 ] JBOSS Not starting
Bugs item #636693, was opened at 2002-11-11 18:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=636693group_id=22866 Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Submitted By: lachu (lachu23) Assigned to: Nobody/Anonymous (nobody) Summary: JBOSS Not starting Initial Comment: i download the jboss server (jboss3.0 zip) and extracted to my D drive.when i run the Run.bat.it is throwing the below exception.iam using java 1.4.0 JVM in my machine. log4j:ERROR Could not instantiate class [org.jboss.logging.appender.FileAppender ]. java.lang.ClassNotFoundException: org.jboss.logging.appender.FileAppender at java.net.URLClassLoader$1.run (URLClassLoader.java:198) at java.security.AccessController.doPrivileged (Native Method) at java.net.URLClassLoader.findClass (URLClassLoader.java:186) at java.lang.ClassLoader.loadClass (ClassLoader.java:306) at java.lang.ClassLoader.loadClass (ClassLoader.java:262) at java.lang.ClassLoader.loadClassInternal (ClassLoader.java:322) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:130) at org.apache.log4j.helpers.OptionConverter.instantiateByCl assName(Optio nConverter.java:301) at org.apache.log4j.helpers.OptionConverter.instantiateByK ey(OptionConve rter.java:116) at org.apache.log4j.PropertyConfigurator.parseAppender (PropertyConfigura tor.java:612) at org.apache.log4j.PropertyConfigurator.parseCategory (PropertyConfigura tor.java:595) at org.apache.log4j.PropertyConfigurator.configureRootCate gory(PropertyC onfigurator.java:502) at org.apache.log4j.PropertyConfigurator.doConfigure (PropertyConfigurato r.java:410) at org.apache.log4j.PropertyConfigurator.doConfigure (PropertyConfigurato r.java:436) at org.apache.log4j.helpers.OptionConverter.selectAndConfi gure(OptionCon verter.java:455) at org.apache.log4j.Category.clinit (Category.java:146) at org.jboss.logging.Logger.init(Logger.java:45) at org.jboss.logging.Logger.getLogger (Logger.java:285) at org.jboss.system.server.ServerImpl.doInit (ServerImpl.java:128) at org.jboss.system.server.ServerImpl.init (ServerImpl.java:112) at org.jboss.Main.boot(Main.java:143) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:536) log4j:ERROR Could not instantiate appender named FILE. 22:47:40,771 INFO [Server] JBoss Release: JBoss- 3.0.4 CVSTag=JBoss_3_0_4 22:47:40,811 INFO [Server] Home Dir: D:\jboss-3.0.4 22:47:40,811 INFO [Server] Home URL: file:/D:/jboss- 3.0.4/ 22:47:40,811 INFO [Server] Library URL: file:/D:/jboss- 3.0.4/lib/ 22:47:40,811 INFO [Server] Patch URL: null 22:47:40,811 INFO [Server] Server Name: default 22:47:40,811 INFO [Server] Server Home Dir: D:\jboss- 3.0.4\server\default 22:47:40,821 INFO [Server] Server Home URL: file:/D:/jboss-3.0.4/server/default / 22:47:40,831 INFO [Server] Server Data Dir: D:\jboss- 3.0.4\server\default\db 22:47:40,841 INFO [Server] Server Temp Dir: D:\jboss- 3.0.4\server\default\tmp 22:47:40,851 INFO [Server] Server Config URL: file:/D:/jboss-3.0.4/server/defau lt/conf/ 22:47:40,861 INFO [Server] Server Library URL: file:/D:/jboss-3.0.4/server/defa ult/lib/ 22:47:40,881 INFO [Server] Root Deployemnt Filename: jboss-service.xml 22:47:40,901 INFO [Server] Starting General Purpose Architecture (GPA)... 22:47:41,442 ERROR [Server] start failed java.lang.NoSuchMethodError: org.apache.log4j.Category.getEffectiveLevel()Lorg/a pache/log4j/Level; at org.jboss.logging.Logger.isDebugEnabled (Logger.java:108) at org.jboss.system.server.ServerImpl.initBootLibraries (ServerImpl.java: 377) at org.jboss.system.server.ServerImpl.doStart (ServerImpl.java:261) at org.jboss.system.server.ServerImpl.start (ServerImpl.java:221) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:536) java.lang.NoSuchMethodError: org.apache.log4j.Category.getEffectiveLevel()Lorg/a pache/log4j/Level; at org.jboss.logging.Logger.isDebugEnabled (Logger.java:108) at org.jboss.system.server.ServerImpl.initBootLibraries (ServerImpl.java: 377) at org.jboss.system.server.ServerImpl.doStart (ServerImpl.java:261) at org.jboss.system.server.ServerImpl.start (ServerImpl.java:221) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:536) -- Comment By: Christian Riege (lqd) Date: 2002-11-20 11:51 Message: Logged In: YES user_id=176671 are you using the official zip distribution as obtained from sourceforge? works for me w/o any problems. try re-downloading.
[JBoss-dev] [ jboss-Bugs-641155 ] EAR file class scoping problem
Bugs item #641155, was opened at 2002-11-20 11:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641155group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Giles Paterson (gpaterson) Assigned to: Nobody/Anonymous (nobody) Summary: EAR file class scoping problem Initial Comment: JBoss: 3.0.4 OS: Windows 2000 Server Java Version: java version 1.3.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01) Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode) This bug report has been created at the request of Scott M Stark in response to my posting to the jboss-user mailing list Here is the content of the email I sent to the mailing list: --- For the full details, take a look at the following forum thread: http://www.jboss.org/forums/thread.jsp?forum=47thread=24806 Basically, I have an EAR file that is structured like this: main.ear: some_ejbs.jar some_more_ejbs.jar a_web_app.war lib/ third_party_libs.jar common_code.jar META-INF/ application.xml This jar was working perfectly under Weblogic 6.1, but just doesn't want to play when ported to JBoss 3.0.4 (Yes, JBoss specific deployment descriptors have been added to the various EJB jars). It is worth noting that the MANIFEST.MF files for the EJB Jars and the War file reference various third party and common jars in the Class-Path element. Initially I was encountering all sorts of IllegalAccessErrors and NoClassDefFoundErrors, and adding a jboss-app.xml file to the Ear to scope the classes didn't help at all. I was making some progress by manually adding various jars to the JBoss start-up classpath but that wasn't a great solution. Finally I tried unpacking the EAR file into a subdirectory of the deploy directory and the application suddenly started working (with no additional jars in the JBoss start-up classpath). However, if I removed the jboss-app.xml file from the expanded directory, the application would stop working and give me IllegalAccessErrors again. This suggests to me that Class scoping doesn't always work in 3.0.4 if the application is packaged in an EAR file, but it does work if the EAR file is expanded out into a directory. After some further trawling of the mailing list archives, I believe this may be related to the fact that my EJB jars, reference the same common and third party jars in their MANIFEST.MF Class-Path entries (There was a thread concerning this back in August/September http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg20584.html ), and possibly to bug #602828 Currently, I am satisfied with deploy my app as an expanded EAR directory, but I would prefer to use an EAR as it simplifies the deployment process. Does anyone have any comments or suggestions concerning this? I haven't had a chance to delve into the JBoss code yet, but I'm intrigued as to why the Class loading works differently for Ear files as compared to expanded directories. --- I have been unable, so far, to create a simple test ear that recreates the problem, so I have instead attached a UCL log file. I will attempt to create an example EAR file and upload that when I get a chance. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641155group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-641155 ] EAR file class scoping problem
Bugs item #641155, was opened at 2002-11-20 11:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641155group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Giles Paterson (gpaterson) Assigned to: Nobody/Anonymous (nobody) Summary: EAR file class scoping problem Initial Comment: JBoss: 3.0.4 OS: Windows 2000 Server Java Version: java version 1.3.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01) Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode) This bug report has been created at the request of Scott M Stark in response to my posting to the jboss-user mailing list Here is the content of the email I sent to the mailing list: --- For the full details, take a look at the following forum thread: http://www.jboss.org/forums/thread.jsp?forum=47thread=24806 Basically, I have an EAR file that is structured like this: main.ear: some_ejbs.jar some_more_ejbs.jar a_web_app.war lib/ third_party_libs.jar common_code.jar META-INF/ application.xml This jar was working perfectly under Weblogic 6.1, but just doesn't want to play when ported to JBoss 3.0.4 (Yes, JBoss specific deployment descriptors have been added to the various EJB jars). It is worth noting that the MANIFEST.MF files for the EJB Jars and the War file reference various third party and common jars in the Class-Path element. Initially I was encountering all sorts of IllegalAccessErrors and NoClassDefFoundErrors, and adding a jboss-app.xml file to the Ear to scope the classes didn't help at all. I was making some progress by manually adding various jars to the JBoss start-up classpath but that wasn't a great solution. Finally I tried unpacking the EAR file into a subdirectory of the deploy directory and the application suddenly started working (with no additional jars in the JBoss start-up classpath). However, if I removed the jboss-app.xml file from the expanded directory, the application would stop working and give me IllegalAccessErrors again. This suggests to me that Class scoping doesn't always work in 3.0.4 if the application is packaged in an EAR file, but it does work if the EAR file is expanded out into a directory. After some further trawling of the mailing list archives, I believe this may be related to the fact that my EJB jars, reference the same common and third party jars in their MANIFEST.MF Class-Path entries (There was a thread concerning this back in August/September http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg20584.html ), and possibly to bug #602828 Currently, I am satisfied with deploy my app as an expanded EAR directory, but I would prefer to use an EAR as it simplifies the deployment process. Does anyone have any comments or suggestions concerning this? I haven't had a chance to delve into the JBoss code yet, but I'm intrigued as to why the Class loading works differently for Ear files as compared to expanded directories. --- I have been unable, so far, to create a simple test ear that recreates the problem, so I have instead attached a UCL log file. I will attempt to create an example EAR file and upload that when I get a chance. -- Comment By: Giles Paterson (gpaterson) Date: 2002-11-20 11:21 Message: Logged In: YES user_id=124102 Well, the zipped UCL log was too large to attach here, so I've emailed it to Scott Stark instead. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641155group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Branch 3.2 doesn't build?
hi dominik, On Tue, 2002-11-19 at 22:05, Dominik Kacprzak wrote: I'm running into the same problem as Christian on RH Linux 8.0 even tho my ANT_HOME is not set. On my box, I have the following ant rpms installed. ant-optional-full-1.5.1-3jpp ant-1.5.1-3jpp this is my setup, too (except for the fact that i'm on RedHat 7.1 and not 8.0 but that should not matter). scott updated the ant .jar files to 1.5.1 yesterday (for Branch_3_2). that seemed to fix my problem but only for a short time, somehow i managed to set other things, too -- once i exited that shell, it was broken again. the basic problem is that ant reads in your /etc/ant.conf file which apparently breaks the build. i will have one more try of fixing this today as CVS HEAD is working just fine (then again the build.sh files are totally different for the two). you can solve your problem manually by editing jboss-dir/tools/bin/ant by hand and commenting out the first 3 or 4 lines where it reads in your /etc/ant.conf file -- works for me. best regards, christian --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss-3.2.0beta2 released
The JBoss-3.0.2beta2 release has been made available at sourceforge. The binaries and source may be obtained from here: http://sourceforge.net/project/showfiles.php?group_id=22866 The release notes are available here: http://sourceforge.net/project/shownotes.php?release_id=13 Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-641224 ] Chronic NPE in ClientContainer.java
Bugs item #641224, was opened at 2002-11-20 15:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641224group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Oskari Kettunen (aok) Assigned to: Nobody/Anonymous (nobody) Summary: Chronic NPE in ClientContainer.java Initial Comment: patch #639788 removed superfluous Map instatiations from ./server/src/main/org/jboss/invocation/Invocation.jav a, however he submitter overlooked the use of the no args constructor from ./server/src/main/org/jboss/proxy/ClientContainer.java ./server/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/J DBCCMRFieldBridge.java (the list is longer in HEAD) This causes chronic NullPointerExceptions. I didn't bother to find out whether all uses of Invocation could be directed to the constructor with arguments. A quick fix is to initialise the maps in all constructors. (see attached diff) Oskari Kettunen, Krocus Communications, Finland -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641224group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-641224 ] Chronic NPE in ClientContainer.java
Bugs item #641224, was opened at 2002-11-20 14:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641224group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: Accepted Priority: 5 Submitted By: Oskari Kettunen (aok) Assigned to: Christian Riege (lqd) Summary: Chronic NPE in ClientContainer.java Initial Comment: patch #639788 removed superfluous Map instatiations from ./server/src/main/org/jboss/invocation/Invocation.jav a, however he submitter overlooked the use of the no args constructor from ./server/src/main/org/jboss/proxy/ClientContainer.java ./server/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/J DBCCMRFieldBridge.java (the list is longer in HEAD) This causes chronic NullPointerExceptions. I didn't bother to find out whether all uses of Invocation could be directed to the constructor with arguments. A quick fix is to initialise the maps in all constructors. (see attached diff) Oskari Kettunen, Krocus Communications, Finland -- Comment By: Christian Riege (lqd) Date: 2002-11-20 15:42 Message: Logged In: YES user_id=176671 woops. actually i was thinking about this problem as i went ahead and then i just forgot or something. will fix immediately. thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641224group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-641224 ] Chronic NPE in ClientContainer.java
Bugs item #641224, was opened at 2002-11-20 14:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641224group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Oskari Kettunen (aok) Assigned to: Christian Riege (lqd) Summary: Chronic NPE in ClientContainer.java Initial Comment: patch #639788 removed superfluous Map instatiations from ./server/src/main/org/jboss/invocation/Invocation.jav a, however he submitter overlooked the use of the no args constructor from ./server/src/main/org/jboss/proxy/ClientContainer.java ./server/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/J DBCCMRFieldBridge.java (the list is longer in HEAD) This causes chronic NullPointerExceptions. I didn't bother to find out whether all uses of Invocation could be directed to the constructor with arguments. A quick fix is to initialise the maps in all constructors. (see attached diff) Oskari Kettunen, Krocus Communications, Finland -- Comment By: Christian Riege (lqd) Date: 2002-11-20 15:55 Message: Logged In: YES user_id=176671 fixed in 3.0, 3.2 and HEAD. Now I see why I let this slip: the no-args constructor had a only for externalization support comment above it and the copy-constructor needed to create new HashMap objects anyways ... my bad. -- Comment By: Christian Riege (lqd) Date: 2002-11-20 15:42 Message: Logged In: YES user_id=176671 woops. actually i was thinking about this problem as i went ahead and then i just forgot or something. will fix immediately. thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641224group_id=22866 --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Unneccessary Jetty error in 3.2
The exception is there and I just siad it could be safely ignored. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jules Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 20, 2002 1:56 AM Subject: Re: [JBoss-dev] Unneccessary Jetty error in 3.2 My mistake - I've got too used to only running 'all'. Since I see that you have now released the new beta, what is the status of this ? Have you included JavaGroups in default ? Or is the Exception still there ? Jules --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [JBoss-user] JBoss-3.2.0beta2 released
Re: the : java.lang.ClassNotFoundException: Unexpected error during load of: org.mortbay.j2ee.session.JGStore, msg=org/javagroups/MessageListener that you get when starting the 'default' configuration. Simply copying the javagroups.jar from server/all/lib into server/default/lib should put a stop to this. Sorry guys, Jules Scott M Stark wrote: The JBoss-3.0.2beta2 release has been made available at sourceforge. The binaries and source may be obtained from here: http://sourceforge.net/project/showfiles.php?group_id=22866 The release notes are available here: http://sourceforge.net/project/shownotes.php?release_id=13 Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user This email has been scanned for all viruses by the MessageLabs SkyScan service. For more information on a proactive anti-virus service working around the clock, around the globe, visit http://www.messagelabs.com --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] authenticating using a non-text credential (ObjectCallback)
I am trying to allow a login using an X509 Certificate as a credential. My login module uses an ObjectCallback to retrieve the certificate. All is fine and dandy if I do something like this: String domain = authMgr.getSecurityDomain(); ObjectCallbackHandler och = new ObjectCallbackHandler(cert); // use my own callback handler LoginContext lc = new LoginContext(domain, och); lc.login(); but further on down the road (mere milliseconds later actually) when the JaasSecurityManager attempts to call its isValid(Principal, Object) method, the SecurityAssiciationHandler (used in the private defaultLogin() method) chokes on the callback. I am storing the credential (certificate) in SecurityAssociation, which allows any object to be held as a credential. Do I need to extend the JaasSecurityManager (actually JaasSecurityDomain) to be able to properly verify ( isValid() ) this type of credential, or am I making things more difficult than they should be? Thanks -jason
[JBoss-dev] [ jboss-Bugs-640991 ] field names are not quoted
Bugs item #640991, was opened at 2002-11-19 18:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=640991group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Adam Heath (doogie) Assigned to: Dain Sundstrom (dsundstrom) Summary: field names are not quoted Initial Comment: Certain databases have certain keywords reserved. To prevent this, *all* table names, and *all* column names must be quoted. To observe this very broken behaviour, do the following: 1. Download ITracker(www.sf.net/projects/itracker, version 1.4.0) 2. Convert the ear to an unpacked form(unzip, rename, unpack, etc) 3. Change standardjbosscmp-jdbc.xml to use a type mapping of PostgreSQL. 4. Disable(or remove) server/default/deploy/hsqldb-service.xml 5. Add postgresql.jar to server/default/deploy 6. Add postgresql-service.xml to server/default/deploy 7. Add itracker.ear to server/default/deploy 8. bin/run.sh Postgres will have an error parsing the generated sql, because this code uses a CMR of 'user', which is a reserved word. If I cut and paste the generated CREATE TABLE command into psql, and use to quote user, it will eventually deploy. But then, later on, it'll fail as it tries to query and set the values. Since JBoss can have no way of knowing this kind of information, *all* such non-sql keywords should be quoted. This bug first discovered on 3.0.1, and I just downloaded a brand new 3.0.4, to verify it's existance(which is how I knew the exact steps to duplicate it). I'm running postgres 7.2.1. Debian unstable(sid), i386. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-20 10:44 Message: Logged In: YES user_id=251431 Adam, This is definately a feature request; you are requesting that JBossCMP support a specifc legacy mapping. This is equivlent to the feature request for not null foriegn keys. I am sure people that need not-null foreign key support consider it a bug. We simply cannot consider all unsuported mappings bugs. -- Comment By: Kevin Conner (kevinconner) Date: 2002-11-20 03:17 Message: Logged In: YES user_id=598569 Hiya Dain. I have already got a patch for the 3.0.2 source that fixes this. I've been meaning to post it for a while but things have gotten very hectic here :-), personally and professionally. I'm going to have a look at moving my patches to the 3.0.4 source this weekend and will post something at the beginning of next week. BTW I had to jump through a lot of hoops to get the metadata consistent, would you expect this? Kev -- Comment By: Adam Heath (doogie) Date: 2002-11-20 01:01 Message: Logged In: YES user_id=9692 Well, I still consider this a bug, that should remain open. 'user' is a very common name, both in database implementations and in user code. If you can tell me that the only place sql is generated is in the compiler classes, then I can have a go at adding code to do this escaping. My question then becomes how best to export this feature into the configuration space. Should it be part of standardjbosscmp-jdbc.xml, globally, or inside each ejb, per field/entity, or a combination of all? As to making the sql harder to read, why is that a problem? JBoss is supposed to hide all this database complexity, no one should ever need to read the sql, *ever*. If everything works, then all a user/developer needs to be concerned with is calilng methods on entities. This kind of bug exposes problems with the underlying database, which is one of the main driving forces j2ee container systems are supposed to hide. The note about case sensitvity is a valid point, however. It's such a shame sql is so shitty in this regard. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-20 00:26 Message: Logged In: YES user_id=251431 Adam please read the feature list before posting. This has been a know issue for a long time (see feature request 555315). The reason I didn't code it that way, was I personally would never use any name that had to be quoted in a database. Anyway, it is not true that all databases support quoted identifiers. We actually need to check the database metadata first. Also I think we should not use quotes unless absolutely necessary as it makes the SQL harder to read. -dain -- Comment By: Jeremy Boynes (jboynes) Date: 2002-11-20 00:07 Message: Logged In: YES user_id=378919 Another consequence of quoting is to make name matching case sensitive (normally it is case blind). As least that what SQL-92 says, not all databases do it. I believe this would lead to confusion as JBoss would be
[JBoss-dev] [ jboss-Bugs-640991 ] field names are not quoted
Bugs item #640991, was opened at 2002-11-19 18:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=640991group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Adam Heath (doogie) Assigned to: Dain Sundstrom (dsundstrom) Summary: field names are not quoted Initial Comment: Certain databases have certain keywords reserved. To prevent this, *all* table names, and *all* column names must be quoted. To observe this very broken behaviour, do the following: 1. Download ITracker(www.sf.net/projects/itracker, version 1.4.0) 2. Convert the ear to an unpacked form(unzip, rename, unpack, etc) 3. Change standardjbosscmp-jdbc.xml to use a type mapping of PostgreSQL. 4. Disable(or remove) server/default/deploy/hsqldb-service.xml 5. Add postgresql.jar to server/default/deploy 6. Add postgresql-service.xml to server/default/deploy 7. Add itracker.ear to server/default/deploy 8. bin/run.sh Postgres will have an error parsing the generated sql, because this code uses a CMR of 'user', which is a reserved word. If I cut and paste the generated CREATE TABLE command into psql, and use to quote user, it will eventually deploy. But then, later on, it'll fail as it tries to query and set the values. Since JBoss can have no way of knowing this kind of information, *all* such non-sql keywords should be quoted. This bug first discovered on 3.0.1, and I just downloaded a brand new 3.0.4, to verify it's existance(which is how I knew the exact steps to duplicate it). I'm running postgres 7.2.1. Debian unstable(sid), i386. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-20 10:48 Message: Logged In: YES user_id=251431 Kevin, please post your patch even if you don't have the time to update it for 3.0.4. Someone will update it. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-20 10:44 Message: Logged In: YES user_id=251431 Adam, This is definately a feature request; you are requesting that JBossCMP support a specifc legacy mapping. This is equivlent to the feature request for not null foriegn keys. I am sure people that need not-null foreign key support consider it a bug. We simply cannot consider all unsuported mappings bugs. -- Comment By: Kevin Conner (kevinconner) Date: 2002-11-20 03:17 Message: Logged In: YES user_id=598569 Hiya Dain. I have already got a patch for the 3.0.2 source that fixes this. I've been meaning to post it for a while but things have gotten very hectic here :-), personally and professionally. I'm going to have a look at moving my patches to the 3.0.4 source this weekend and will post something at the beginning of next week. BTW I had to jump through a lot of hoops to get the metadata consistent, would you expect this? Kev -- Comment By: Adam Heath (doogie) Date: 2002-11-20 01:01 Message: Logged In: YES user_id=9692 Well, I still consider this a bug, that should remain open. 'user' is a very common name, both in database implementations and in user code. If you can tell me that the only place sql is generated is in the compiler classes, then I can have a go at adding code to do this escaping. My question then becomes how best to export this feature into the configuration space. Should it be part of standardjbosscmp-jdbc.xml, globally, or inside each ejb, per field/entity, or a combination of all? As to making the sql harder to read, why is that a problem? JBoss is supposed to hide all this database complexity, no one should ever need to read the sql, *ever*. If everything works, then all a user/developer needs to be concerned with is calilng methods on entities. This kind of bug exposes problems with the underlying database, which is one of the main driving forces j2ee container systems are supposed to hide. The note about case sensitvity is a valid point, however. It's such a shame sql is so shitty in this regard. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-20 00:26 Message: Logged In: YES user_id=251431 Adam please read the feature list before posting. This has been a know issue for a long time (see feature request 555315). The reason I didn't code it that way, was I personally would never use any name that had to be quoted in a database. Anyway, it is not true that all databases support quoted identifiers. We actually need to check the database metadata first. Also I think we should not use quotes unless absolutely necessary as it makes the SQL harder to read. -dain -- Comment By: Jeremy Boynes
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 20-November-2002
Number of tests run: 995 Successful tests: 987 Errors:7 Failures: 1 [time of test: 2002-11-20.11-56 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.2] See http://users.jboss.org/~starksm/Branch_3_0/2002-11-20.11-56 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- This sf.net email is sponsored by: Battle your brains against the best in the Thawte Crypto Challenge. Be the first to crack the code - register now: http://www.gothawte.com/rd521.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-640991 ] field names are not quoted
Bugs item #640991, was opened at 2002-11-20 00:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=640991group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Adam Heath (doogie) Assigned to: Dain Sundstrom (dsundstrom) Summary: field names are not quoted Initial Comment: Certain databases have certain keywords reserved. To prevent this, *all* table names, and *all* column names must be quoted. To observe this very broken behaviour, do the following: 1. Download ITracker(www.sf.net/projects/itracker, version 1.4.0) 2. Convert the ear to an unpacked form(unzip, rename, unpack, etc) 3. Change standardjbosscmp-jdbc.xml to use a type mapping of PostgreSQL. 4. Disable(or remove) server/default/deploy/hsqldb-service.xml 5. Add postgresql.jar to server/default/deploy 6. Add postgresql-service.xml to server/default/deploy 7. Add itracker.ear to server/default/deploy 8. bin/run.sh Postgres will have an error parsing the generated sql, because this code uses a CMR of 'user', which is a reserved word. If I cut and paste the generated CREATE TABLE command into psql, and use to quote user, it will eventually deploy. But then, later on, it'll fail as it tries to query and set the values. Since JBoss can have no way of knowing this kind of information, *all* such non-sql keywords should be quoted. This bug first discovered on 3.0.1, and I just downloaded a brand new 3.0.4, to verify it's existance(which is how I knew the exact steps to duplicate it). I'm running postgres 7.2.1. Debian unstable(sid), i386. -- Comment By: Adam Heath (doogie) Date: 2002-11-20 21:35 Message: Logged In: YES user_id=9692 Hmm. I was talking with my boss about this at lunch, and we realized what the real problem probably is. For standard CMP fields, the name used in the code is disconnected from the column name used in the database. ejb-jar.xml allows for this change of name. However, I am not aware of being able to choose the column name for a CMR field in this same matter. The real solution to this problem seems to be would be to add such a feature, maybe in an extended jboss descriptor. This way, it's completely generic, as it should be. Is this even possible? If so, if someone could tell me the name of the doc or howto or whatever(don't bother telling me where, I can find it from the name), I'd be most grateful. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-20 16:48 Message: Logged In: YES user_id=251431 Kevin, please post your patch even if you don't have the time to update it for 3.0.4. Someone will update it. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-11-20 16:44 Message: Logged In: YES user_id=251431 Adam, This is definately a feature request; you are requesting that JBossCMP support a specifc legacy mapping. This is equivlent to the feature request for not null foriegn keys. I am sure people that need not-null foreign key support consider it a bug. We simply cannot consider all unsuported mappings bugs. -- Comment By: Kevin Conner (kevinconner) Date: 2002-11-20 09:17 Message: Logged In: YES user_id=598569 Hiya Dain. I have already got a patch for the 3.0.2 source that fixes this. I've been meaning to post it for a while but things have gotten very hectic here :-), personally and professionally. I'm going to have a look at moving my patches to the 3.0.4 source this weekend and will post something at the beginning of next week. BTW I had to jump through a lot of hoops to get the metadata consistent, would you expect this? Kev -- Comment By: Adam Heath (doogie) Date: 2002-11-20 07:01 Message: Logged In: YES user_id=9692 Well, I still consider this a bug, that should remain open. 'user' is a very common name, both in database implementations and in user code. If you can tell me that the only place sql is generated is in the compiler classes, then I can have a go at adding code to do this escaping. My question then becomes how best to export this feature into the configuration space. Should it be part of standardjbosscmp-jdbc.xml, globally, or inside each ejb, per field/entity, or a combination of all? As to making the sql harder to read, why is that a problem? JBoss is supposed to hide all this database complexity, no one should ever need to read the sql, *ever*. If everything works, then all a user/developer needs to be concerned with is calilng methods on entities. This kind of bug exposes problems with the underlying database, which is one of the main driving forces j2ee container systems are supposed
