[JBoss-dev] [ jboss-Bugs-546940 ] classes not loaded from WEB-INF/classes
Bugs item #546940, was opened at 2002-04-21 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=546940group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Scott McLaughlin (mclaugs) Assigned to: Scott M Stark (starksm) Summary: classes not loaded from WEB-INF/classes Initial Comment: classes are not being loaded from the WEB-INF/classes directory of a .war archive. This problem exists in the current Branch_3_0 and HEAD(2002-04-21 22:43EST) The only error in the log is a java.lang.ClassNotFoundException loading of the classes directory was working about a week ago. A work around for this problem is to jar the class files and place the archive in the WEB-INF/lib directory. Linux,Win2000 Sun 1.3.1 JDK -- Comment By: Scott M Stark (starksm) Date: 2002-04-25 23:42 Message: Logged In: YES user_id=175228 Provide a testcase that demonstrates this as the current web integration unit test includes a test of loading classes from WEB-INF/classes -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=546940group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-548668 ] 3RC1-catalina invokeHome/classload prob
Bugs item #548668, was opened at 2002-04-25 08:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548668group_id=22866 Category: CatalinaBundle Group: CVS HEAD Status: Closed Resolution: Fixed Priority: 7 Submitted By: David Ward (dward2) Assigned to: Scott M Stark (starksm) Summary: 3RC1-catalina invokeHome/classload prob Initial Comment: Operating System: RedHat Linux 7.1, kernel 2.4.31-i386, windows, others. JDK Version: 1.3.1_03, others There is a problem with jboss-3.0.0RC1_tomcat-4.0.3 where including the home and remote (or local-home and local) EJB interfaces in the WAR file causes a NPE during StatelessSessionContainer$ContainerInterceptor.invokeHome. Removing the EJB interfaces from the WAR file causes the problem to dissappear. Not sure if this is a JBoss unified classloader problem or a catalina servlet 2.3 classloader problem, or a mix. This problem does not happen with JBoss2.4 + catalina. *Lots* of people have complained about this on the email lists under different subject titles, but here is a link to one as an example, which also includes a stack trace: http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg15351.html This bug is a killer for people who need to keep their application bundles cross-appserver compatible. Thanks! David -- Comment By: Scott M Stark (starksm) Date: 2002-04-25 23:44 Message: Logged In: YES user_id=175228 The Java2 parent delegation class loading model has been restored to circumvent this issue. If you enable the servlet 2.3 class loading model using the Java2ClassLoadingCompliance attribute then you are responsible for packaging the classes appropriately. -- Comment By: Scott M Stark (starksm) Date: 2002-04-25 11:59 Message: Logged In: YES user_id=175228 Only the NPE is a bug. When fixed this will result in a ClassCastException due to the default optimization of servlet to ejb call and the fact that duplicate classes are included in the ear, and the servlet 2.3 class loading model which will load the war level classes before those visible to the web context parent class loader. In 3.0 the behavior of downgrading a call to use serialization when incompatibles classes where seen was dropped. It would be a request for enhancement to or a seperate bug to restore this behavior. It is not a violation of any j2ee spec to not include the ejb interfaces in the war. The 1.3 j2eeri will deploy such an ear that includes a jsp page calling an ejb. The 1.3 j2eeri will also deploy a war that does include the ejb interfaces in the war. Compatability with such a packaging should be supported. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548668group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-529311 ] jboss_3_0.dtd on www.jboss.org
Bugs item #529311, was opened at 2002-03-12 23:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=529311group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 1 Submitted By: Vincent Harcq (vharcq) Assigned to: Jason Dillon (user57) Summary: jboss_3_0.dtd on www.jboss.org Initial Comment: The DTD http://www.jboss.org/j2ee/dtd/jboss_3_0.dtd is missing and external resolution of it break. -- Comment By: Jason Dillon (user57) Date: 2002-04-04 16:33 Message: Logged In: YES user_id=15045 Yes, this needs to be fixed... will get to it when updating the website in the coming days/weeks. --jason -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=529311group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-548586 ] CMP entity bean remove from JSP fails
Bugs item #548586, was opened at 2002-04-25 06:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548586group_id=22866 Category: CatalinaBundle Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Petr Hubený (psh) Assigned to: Scott M Stark (starksm) Summary: CMP entity bean remove from JSP fails Initial Comment: I've a CMP entity EJB with class PK. Using findByPrimaryKey() and remove() works fine from standalone client, however fails from JSP under 2.4.5RC2 with Tomcat/Catalina 4.0.3. It also works under 2.4.4 with Tomcat 3.2.3. The failure is accompanied with Failed to load/IllegalArgumentException screams, which appears strange, since the bean is already successfully loaded (the findByPrimaryKey() is OK, also getters on the bean work fine, just the remove() fails). Simple example of failure is attached, try the /Test/test.jsp to insert and (fail to) remove data (master and slave are integers, value is String). Oh, yeah, I tried the bundle JBoss-2.4.5_Tomcat-4.0.3.zip (it is RC1, I believe) on Linux with JDK 1.4.0-b92 and on Windows with JDK 1.4.0-b92 and JDK 1.3.1_01, fails everywhere. Then I tried JBoss-2.4.5RC2_Tomcat-4.0.3.zip on Linux (JDK 1.4.0), fails as well. Next I tried the old JBoss-2.4.4_Tomcat-3.2.3.zip on Linux (JDK 1.4.0) and it works. psh -- Comment By: Scott M Stark (starksm) Date: 2002-04-25 23:41 Message: Logged In: YES user_id=175228 This is because you have the ejb interfaces in the war and the servlet 2.3 class loading model is conflicting with the classes loaded by the ejb. The Java2 parent delegation class loading model has been restored. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548586group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-515542 ] getRemote in MBean view throws NPE
Bugs item #515542, was opened at 2002-02-10 08:35
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=515542group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Georg Schmid (giorgio42)
Assigned to: marc fleury (mnf999)
Summary: getRemote in MBean view throws NPE
Initial Comment:
Basic info:
INFO JBoss (MX MicroKernel) 3.0.0DR1(200202092237)
[RABBIT-HOLE]
...
11:40:24,734 INFO [Info] Java version: 1.3.1_02,Sun
Microsystems Inc.
11:40:24,734 INFO [Info] Java VM: Java HotSpot(TM)
Client VM 1.3.1_02-b02,Sun Microsystems Inc.
11:40:24,734 INFO [Info] OS-System: Windows 2000
5.0,x86
Bug:
EJBs are listed in the agent view,
but clicking getRemote/getHome in the Bean View
gives me on the console and the debug log:
2002-02-10 17:29:42,093 ERROR
[org.jboss.ejb.EntityContainer] invoke returned an
exception
java.lang.NullPointerException
at org.jboss.ejb.Container.invoke
(Container.java:563)
at org.jboss.ejb.EntityContainer.invoke
(EntityContainer.java:990)
at
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1555)
at
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1523)
at com.sun.jdmk.comm.HtmlInvokePage.buildPage
(HtmlInvokePage.java:240)
at
com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest
(HtmlRequestHandler.java:325)
at
com.sun.jdmk.comm.HtmlRequestHandler.processRequest
(HtmlRequestHandler.java:152)
at com.sun.jdmk.comm.HtmlRequestHandler.doRun
(HtmlRequestHandler.java:79)
at com.sun.jdmk.comm.ClientHandler.run
(ClientHandler.java:84)
at java.lang.Thread.run(Unknown Source)
and of course an 472 MBean failure
The MBean
[jboss.j2ee:service=EJB,jndiName=ejb/entities/Entity]
throws an MBeanException when calling [getRemote]:
java.lang.NullPointerException
on the page.
A grep on the debug log shows:
server.log.1:2002-02-10 16:48:50,640 DEBUG
[org.jboss.proxy.ejb.ProxyFactory] Bound EntityEB to
ejb/entities/Entity
And I cannot get access to any home interface from the
client. The call does not even reach the server. But
this may be a different story.
Georg
--
I'm not living for you, I'm living for me. (Garland
Jeffreys)
--
Comment By: David Jencks (d_jencks)
Date: 2002-02-19 23:22
Message:
Logged In: YES
user_id=60525
The npe is caused by null instead of new
MBeanParameterInfo[] {}. I'm fixing this. When it's fixed,
then you get a different error;-) caused as marc explains.
Does anyone have a problem with implementing these methods
as regular DynamicMBean methods as well as the shortcuts?
--
Comment By: Jason Dillon (user57)
Date: 2002-02-13 00:17
Message:
Logged In: YES
user_id=15045
With the current optimization hacks around the container,
any client that does not provide an Invocation object which
contains the method call information will fail.
Need to talk to Marc about this.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=515542group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-512788 ] Problem with WAR.
Bugs item #512788, was opened at 2002-02-04 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=512788group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Infogest (infogest) Assigned to: Jules Gosnell (jules_gosnell) Summary: Problem with WAR. Initial Comment: When trying to access a class to be loaded from WEB-INF/classes from within a class loaded from WEB-INF/lib/myjar.jar there is a ClassNotFoundException. I temporarly resolved putting WEB-INF/classes into the UnifiedClassLoader, with a dirty (very dirty) patch of DeploymentInfo, waiting for somthing better ... -- Comment By: Jules Gosnell (jules_gosnell) Date: 2002-04-02 16:24 Message: Logged In: YES user_id=49106 same symptoms as [537163 ] Deployed .WAR file classloading problem. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=512788group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-527280 ] Deployment of ear fails (jzenty problem)
Bugs item #527280, was opened at 2002-03-07 22:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=527280group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Markus Menner (morphace) Assigned to: Nobody/Anonymous (nobody) Summary: Deployment of ear fails (jzenty problem) Initial Comment: I noticed a similar problem as of bug 522617, when I deploy a ear. I use the snapshot of 03072002. My ear contains a war (web-app) and a jar (ejbs). I get the following error message: 07:56:01,456 ERROR [MainDeployer] Couldn't deploy URL file:/opt/jt/deploy/broker.ear org.jboss.deployment.DeploymentException: Could not create deployment: file:/opt/jt/server/default/tmp/deploy/broker.war; - n java.lang.InternalError: jzentry == 0 at java.util.zip.ZipFile$2.nextElement (ZipFile.java:297) at org.apache.naming.resources.WARDirContext.loadEntries (WARDirContext.java:764) at org.apache.naming.resources.WARDirContext.setDocBase (WARDirContext.java:190) at org.apache.catalina.core.StandardContext.setResources (StandardContext.java:1107) at org.apache.catalina.core.StandardContext.start (StandardContext.java:3301) at org.apache.catalina.core.ContainerBase.addChild (ContainerBase.java:785) at org.apache.catalina.core.StandardHost.addChild (StandardHost.java:454) at org.jboss.web.catalina.EmbeddedCatalinaServiceSX.creat eWebContext(EmbeddedCatalinaServiceSX.java:443) at org.jboss.web.catalina.EmbeddedCatalinaServiceSX.perfo rmDeploy(EmbeddedCatalinaServiceSX.java:287) at org.jboss.web.AbstractWebContainer.start (AbstractWebContainer.java:400) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:624) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:617) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:482) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:454) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:73) at $Proxy2.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.depl oy(URLDeploymentScanner.java:295) at org.jboss.deployment.scanner.URLDeploymentScanner.scan (URLDeploymentScanner.java:406) at org.jboss.deployment.scanner.AbstractDeploymentScanner $ScannerThread.loop (AbstractDeploymentScanner.java:190) at org.jboss.deployment.scanner.AbstractDeploymentScanner $ScannerThread.run(AbstractDeploymentScanner.java:179) org.jboss.deployment.DeploymentException: Could not create deployment: file:/opt/jt/server/default/tmp/deploy/broker.war; - n at org.jboss.deployment.MainDeployer.start (MainDeployer.java:637) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:617) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:482) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:454) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:73) at $Proxy2.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.depl oy(URLDeploymentScanner.java:295) at org.jboss.deployment.scanner.URLDeploymentScanner.scan (URLDeploymentScanner.java:406) at org.jboss.deployment.scanner.AbstractDeploymentScanner $ScannerThread.loop (AbstractDeploymentScanner.java:190) at org.jboss.deployment.scanner.AbstractDeploymentScanner $ScannerThread.run(AbstractDeploymentScanner.java:179) -- Comment By: Markus Menner (morphace) Date: 2002-03-19 23:28 Message: Logged In: YES user_id=472900 Deploying the EJB-jar and the war files separatly works fine! -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=527280group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-508053 ] table creation fails, deploy succeeds
Bugs item #508053, was opened at 2002-01-24 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=508053group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Dain Sundstrom (dsundstrom) Summary: table creation fails, deploy succeeds Initial Comment: RH 3.0 (200200105), W2K, JDK1.3.1_02, Oracle8.1.7 Even if a create table throws an exception during deployment of an entity bean (for instance, because the same column name appears twice in the corresponding jbosscmp-jdbc.xml definition) as can be seen in the debug log, the deployer continues and finally reports Created table xxx successfully and the deployment succeeds. The transaction is rolled back, but otherwise the exception is ignored. Naturally enough, creating instances of the corresponding entity bean fails with table or view does not exist later on: 2002-01-24 17:30:42,864 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.MaintenanceTriggerEB] Executing SQL: CREATE TABLE MAINTENANCE_TRIGGER (ID VARCHAR2(16), TYPE VARCHAR2(16), UNIT VARCHAR2(16), VALUE VARCHAR2(16), LEVEL VARCHAR2(16), CONSTRAINT pk_MAINTENANCE_TRIGGER PRIMARY KEY (ID)) 2002-01-24 17:30:42,864 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.MaintenanceTriggerEB] Could not create table MAINTENANCE_TRIGGER java.sql.SQLException: ORA-00904: invalid column name at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405) at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:822) at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1446) at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1371) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1900) at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:693) at org.jboss.resource.adapter.jdbc.local.StatementInPool.executeUpdate(StatementInPool.java:736) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.createTable(JDBCStartCommand.java:154) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartCommand.java:78) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java:303) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:175) at org.jboss.ejb.EntityContainer.start(EntityContainer.java:341) at org.jboss.ejb.Application.start(Application.java:219) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:389) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:312) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:468) at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:439) at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:203) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.AutoDeployer.deploy(AutoDeployer.java:681) at org.jboss.deployment.AutoDeployer.run(AutoDeployer.java:325) at java.lang.Thread.run(Unknown Source) 2002-01-24 17:30:42,864 DEBUG [org.jboss.tm.TxCapsule] rollback(): Entered, tx=XidImpl [FormatId=257, GlobalId=cna0796942//30, BranchQual=] status=STATUS_ACTIVE 2002-01-24 17:30:42,864 DEBUG [org.jboss.tm.TxManager] rolled back tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=cna0796942//30, BranchQual=] 2002-01-24 17:30:42,864 INFO [org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.MaintenanceTriggerEB] Created table 'MAINTENANCE_TRIGGER' successfully. -- Comment By: Charles Bradley (cbradley2) Date: 2002-04-26 00:03 Message: Logged In: YES user_id=479872 After I posted my comment, I found a workaround. I'm running JBoss 2.4.4 on Win2K/JDK 1.3.1_02, Oracle 8.x. Basically, I just guessed at the SQL statement that JBoss would use to create the table, then I found out through SQL Plus that I had an invalid column name. I guess you can't name a column/EJB attribute 'index' DUUU! I renamed the field(which required a change to ejb-jar.xml as well), and everything worked grand. cb --
[JBoss-dev] [ jboss-Bugs-529880 ] TCat 4.0.2: auth does not work, Jetty OK
Bugs item #529880, was opened at 2002-03-14 05:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=529880group_id=22866 Category: CatalinaBundle Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Finn (mikefinn) Assigned to: Scott M Stark (starksm) Summary: TCat 4.0.2: auth does not work, Jetty OK Initial Comment: Form based authentication does not appear to work in embedded Tomcat, but does with Jetty. OS: Win NT JVM: 1.3.01 JBoss: 3.0 Beta distros from SF (Jetty and Tomcat). I have a web app that uses FORM based authentication. jboss-web.xml and auth.conf are set up to use UserRolesLoginModule. In both Jetty and Tomcat builds, when I deploy the app in Jetty and attempt to access a protected resource, I get my login form. When I log in to the Jetty instance with the correct user/password, I get the requested (protected) page. When I do the same with Tomcat, I get a 403/access denied error page (NOT my form-error- page). Both Jetty and Tomcat instances have the same auth.conf, user.properties, and roles.properties files. I also tested this with standalone Tomcat 4.0.2 (which uses a tomcat-user file that has the same user/password/roles as JBoss/Tomcat|Jetty. This configuration works. Mike -- Comment By: Scott M Stark (starksm) Date: 2002-04-26 00:11 Message: Logged In: YES user_id=175228 This is because Jetty does not use the servlet 2.3 class loading model by default and Tomcat did. It does not longer as this has caused numerous problems when the wars include client jars. -- Comment By: Maurice Schoenmakers (maurice_s) Date: 2002-04-25 23:14 Message: Logged In: YES user_id=526908 Well after a wile of debugging, i figured out that the problemm is caused by different org.jboss.security.SecurityAssociation classes. The current embedded catalina code sets a single JBossSecurityMgrRealm for all deployed web apps. After authentication the principal credential information is set globally using statics in the class org.jboss.security.SecurityAssociation. (to transfer it to the server(easy for sniffers?! ) Unfortunately there are multiple org.jboss.security.SecurityAssociation Classes available: The current code sets the information in the class of the global lib/jbosssx.jar, because the JBossSecurityMgrRealm does not use the correct ClassLoader. Each Web app has an own org.jboss.security.SecurityAssociation Class wich is not accessed by the JBossSecurityMgrRealm (If you include the client jars in your war file). Thus the principalcredential information is never set in the correct class and thus never transferred to the server. After changing the embedding code to set a new JBossSecurityMgrRealm for each deployed WebApp in the contextInit() method things worked fine for me. (I'm not sure how this affects single sign on across multile web apps ? ) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=529880group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Oh yeahh!!! That would be so cool!!! Only one config file, and one bigg monolithic application server that you can configure in this only big file! That would be so cool!!! And if we could merge the database configuration file, OS configuration files and Doom's configuration file in one big file, that would be *really* cool. humpf... -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Juha-P Lindfors Envoye : vendredi, 26 avril 2002 08:05 A : [EMAIL PROTECTED] Objet : [JBoss-dev] [JL] Is it time for a new enterprise solution? Critique on JBoss configuration. http://www.javalobby.org/thread.jsp?forum=61thread=3254 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
(How can one believe that it is possible to configure a whole enterprise from one file?) The critique only means, that Jboss needs a configuration GUI (or at least some command line tool like j2eeadmin). Sun's intention was from the start, that nobody is going to look at the config files themselves. In this way you can design the config files as required by technology. Otherwise you keep running into the conflict between readability/ease of use for humans and usability from the software's perspective. Jboss is a really great product with many features I could not do without. But I cannot understand why the Jboss developers keep badmouthing gui-based solutions. (Don't get me wrong: I am not one of those, who have never seen a command line, just the opposite. VI and the command line have their limitations, though). I predict, that within the next year there will be Jboss-(G)UI, simply driven by public demand. (Look at the Veritas Volume Manager's Java/Swing GUI. Something like that would be great). Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Juha-P Lindfors Sent: Friday, April 26, 2002 08:05 To: [EMAIL PROTECTED] Subject: [JBoss-dev] [JL] Is it time for a new enterprise solution? Critique on JBoss configuration. http://www.javalobby.org/thread.jsp?forum=61thread=3254 -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-548983 ] Wrong mapping for SAPDB type boolean
Bugs item #548983, was opened at 2002-04-26 11:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548983group_id=22866 Category: JBossCMP Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ingo Brüll (ibruell) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong mapping for SAPDB type boolean Initial Comment: In standardjaws.xml and standardjbosscmp-jdbc.xml is a wrong mapping for boolean. It should be: mapping java- typejava.lang.Boolean/java-type jdbc-typeBIT/jdbc- type sql-typeBOOLEAN/sql-type /mapping That affect all versions -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548983group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I totally agree with the article, I believe we should merge our configuration files today, and get rid of the unreadable XML, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha |Labourey |Sent: Friday, April 26, 2002 1:38 AM |To: Juha-P Lindfors; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |Oh yeahh!!! That would be so cool!!! Only one config file, and one |bigg monolithic application server that you can configure in |this only big file! That would be so cool!!! And if we could merge |the database configuration file, OS configuration files and Doom's |configuration file in one big file, that would be *really* cool. | |humpf... | | -Message d'origine- | De : [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]De la part de | Juha-P Lindfors | Envoye : vendredi, 26 avril 2002 08:05 | A : [EMAIL PROTECTED] | Objet : [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | | Critique on JBoss configuration. | | http://www.javalobby.org/thread.jsp?forum=61thread=3254 | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
no it means merging the configuration files, I will do it when I have the time as there is no direction in the configuration files today, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Georg |Schmid |Sent: Friday, April 26, 2002 2:05 AM |To: 'Juha-P Lindfors'; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | |(How can one believe that it is possible to configure a whole enterprise |from one file?) | |The critique only means, that Jboss needs a configuration GUI (or at |least some command line tool like j2eeadmin). | |Sun's intention was from the start, that nobody is going to look at the |config files themselves. |In this way you can design the config files as required by technology. | |Otherwise you keep running into the conflict between readability/ease of |use for humans and |usability from the software's perspective. | |Jboss is a really great product with many features I could not do |without. | |But I cannot understand why the Jboss developers keep badmouthing |gui-based solutions. |(Don't get me wrong: I am not one of those, who have never seen a |command line, just the opposite. VI and |the command line have their limitations, though). | |I predict, that within the next year there will be Jboss-(G)UI, simply |driven by public demand. |(Look at the Veritas Volume Manager's Java/Swing GUI. Something like |that would be great). | |Regards |Georg | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]] On Behalf Of |Juha-P Lindfors |Sent: Friday, April 26, 2002 08:05 |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | |Critique on JBoss configuration. | |http://www.javalobby.org/thread.jsp?forum=61thread=3254 | |-- Juha | | | |___ |Jboss-development mailing list [EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Well, it really depends IMHO. Would you really want to have security information (users, groups, ...) in the same file as the services (jboss-services.xml) ? I am not sure... -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoye : vendredi, 26 avril 2002 14:53 A : Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? I totally agree with the article, I believe we should merge our configuration files today, and get rid of the unreadable XML, ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
You do, this is the production file. There is the development files that really has their own snippets and all and then there is the one big file for the production server approach. I believe we can do this in several steps 1- as today we recommend locking down the server configuration once you are done with development by merging the jboss-services into one big STATIC jboss-services 2- merge ejb-jar jboss jboss-cmp in one big file so your beans are configured in one file. There are many advantages to this approach, namely you get rid of 100% of the indirection. Also it is all well in one page. We did discuss with David in January as to how to do that. 3- merge all of them, mbean,bean so the root tag is jboss mbean bean bla bla bla 4- the last gripe from the thread I am not convinced it had to do with being intimidated by mbean configuration files. I would have to think about this one, there are problems with separating creation and configuration (but it should be done imho) where the creation references a configuration by name, then the XML syntax usage should be simplified as much as possible, avoid XML verbosity, nobody likes it. 5- gui? pf it would need to be a JMX gui in our case, why not, but everybody talks about these and no-one does jack. marcf |-Original Message- |From: Sacha Labourey [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 5:55 AM |To: marc fleury; Sacha Labourey; Juha-P Lindfors; |[EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |Well, it really depends IMHO. Would you really want to have |security information (users, groups, ...) in the same file as the |services (jboss-services.xml) ? I am not sure... | | -Message d'origine- | De : marc fleury [mailto:[EMAIL PROTECTED]] | Envoye : vendredi, 26 avril 2002 14:53 | A : Sacha Labourey; Juha-P Lindfors; | [EMAIL PROTECTED] | Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | I totally agree with the article, I believe we should merge our | configuration files today, and get rid of the unreadable XML, ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
The problem is not the configuration files its the interface. What you really need is a gnome control panel type interface which would allow you to configure and manage your jboss enviroment. This is bigest problem with open source projects, no-one likes writting front ends, it's boring and not sexy. Don't put the configs in 1 file, 20 piles of shit or 1 big pile of shit it is still a pile of shit. On Fri, 2002-04-26 at 08:54, Sacha Labourey wrote: Well, it really depends IMHO. Would you really want to have security information (users, groups, ...) in the same file as the services (jboss-services.xml) ? I am not sure... -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoye : vendredi, 26 avril 2002 14:53 A : Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? I totally agree with the article, I believe we should merge our configuration files today, and get rid of the unreadable XML, ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Marc, I see your point and the interest of such a solution. Nevertheless, there is another problem in fact that *currently* favor the multiple files approach: persistent modification of configuration. Currently (as of 3.0), when you want to modify some service/bean/datasource/whatever, you take its corresponding snippet, modify it and zou, it is re-deployed. First problem: re-deploy should not be, in some cases, undeploy+deploy. Second problem: everything that is in the file is re-deployed. = if you have a single file, you redeploy everything = we tend to have many files now because, currently, many files = fine granularity of redeploy. The second category of problems is about persistence of changes. If you say: F*ck the files, we go through JMX anyway, then any modification made through JMX is *not* persisted (i.e. transient modification). This is a problem, a real problem. The old solution of keeping the old version didn't seem to work well, so it wasn't good either. = IMHO, the problem is not about one vs. multiple files, it is about granularity and persistence of changes (= granularity of redeploy) = maybe the repository approach is a good solution. But *Currently*, with these issues, the multiple-file approach is the best (only?) way to get fine-grained modification of our app server. Cheers, Sacha -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoye : vendredi, 26 avril 2002 15:19 A : Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? You do, this is the production file. There is the development files that really has their own snippets and all and then there is the one big file for the production server approach. I believe we can do this in several steps 1- as today we recommend locking down the server configuration once you are done with development by merging the jboss-services into one big STATIC jboss-services 2- merge ejb-jar jboss jboss-cmp in one big file so your beans are configured in one file. There are many advantages to this approach, namely you get rid of 100% of the indirection. Also it is all well in one page. We did discuss with David in January as to how to do that. 3- merge all of them, mbean,bean so the root tag is jboss mbean bean bla bla bla 4- the last gripe from the thread I am not convinced it had to do with being intimidated by mbean configuration files. I would have to think about this one, there are problems with separating creation and configuration (but it should be done imho) where the creation references a configuration by name, then the XML syntax usage should be simplified as much as possible, avoid XML verbosity, nobody likes it. 5- gui? pf it would need to be a JMX gui in our case, why not, but everybody talks about these and no-one does jack. marcf |-Original Message- |From: Sacha Labourey [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 5:55 AM |To: marc fleury; Sacha Labourey; Juha-P Lindfors; |[EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |Well, it really depends IMHO. Would you really want to have |security information (users, groups, ...) in the same file as the |services (jboss-services.xml) ? I am not sure... | | -Message d'origine- | De : marc fleury [mailto:[EMAIL PROTECTED]] | Envoye : vendredi, 26 avril 2002 14:53 | A : Sacha Labourey; Juha-P Lindfors; | [EMAIL PROTECTED] | Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | I totally agree with the article, I believe we should merge our | configuration files today, and get rid of the unreadable XML, ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I think that is better to have multiple conf files, this resolve the problems described by Sacha (deploy/redeploy). For the GUI problem, I think that we have already implemented jsr 77, we can start to implement jsr 88 and we can wait that SUN :-) extends netbeans to handle these specifications. Claudio -Original Message- From: Sacha Labourey [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 3:30 PM To: marc fleury; Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? Marc, I see your point and the interest of such a solution. Nevertheless, there is another problem in fact that *currently* favor the multiple files approach: persistent modification of configuration. Currently (as of 3.0), when you want to modify some service/bean/datasource/whatever, you take its corresponding snippet, modify it and zou, it is re-deployed. First problem: re-deploy should not be, in some cases, undeploy+deploy. Second problem: everything that is in the file is re-deployed. = if you have a single file, you redeploy everything = we tend to have many files now because, currently, many files = fine granularity of redeploy. The second category of problems is about persistence of changes. If you say: F*ck the files, we go through JMX anyway, then any modification made through JMX is *not* persisted (i.e. transient modification). This is a problem, a real problem. The old solution of keeping the old version didn't seem to work well, so it wasn't good either. = IMHO, the problem is not about one vs. multiple files, it is about granularity and persistence of changes (= granularity of redeploy) = maybe the repository approach is a good solution. But *Currently*, with these issues, the multiple-file approach is the best (only?) way to get fine-grained modification of our app server. Cheers, Sacha -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoye : vendredi, 26 avril 2002 15:19 A : Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? You do, this is the production file. There is the development files that really has their own snippets and all and then there is the one big file for the production server approach. I believe we can do this in several steps 1- as today we recommend locking down the server configuration once you are done with development by merging the jboss-services into one big STATIC jboss-services 2- merge ejb-jar jboss jboss-cmp in one big file so your beans are configured in one file. There are many advantages to this approach, namely you get rid of 100% of the indirection. Also it is all well in one page. We did discuss with David in January as to how to do that. 3- merge all of them, mbean,bean so the root tag is jboss mbean bean bla bla bla 4- the last gripe from the thread I am not convinced it had to do with being intimidated by mbean configuration files. I would have to think about this one, there are problems with separating creation and configuration (but it should be done imho) where the creation references a configuration by name, then the XML syntax usage should be simplified as much as possible, avoid XML verbosity, nobody likes it. 5- gui? pf it would need to be a JMX gui in our case, why not, but everybody talks about these and no-one does jack. marcf |-Original Message- |From: Sacha Labourey [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 5:55 AM |To: marc fleury; Sacha Labourey; Juha-P Lindfors; |[EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |Well, it really depends IMHO. Would you really want to have |security information (users, groups, ...) in the same file as the |services (jboss-services.xml) ? I am not sure... | | -Message d'origine- | De : marc fleury [mailto:[EMAIL PROTECTED]] | Envoye : vendredi, 26 avril 2002 14:53 | A : Sacha Labourey; Juha-P Lindfors; | [EMAIL PROTECTED] | Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | I totally agree with the article, I believe we should merge our | configuration files today, and get rid of the unreadable XML, ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
OK, I agree. (and, I wasn't aware of the PRODUCTION-LOCKING need.) -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoye : vendredi, 26 avril 2002 15:51 A : Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? Sacha, this is configuration for JBoss4.0. bla... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Sacha, this is configuration for JBoss4.0. The fact is that for *production* the one file is good. For actually administering and configuring a server the many files is better, yes, but they are different world, the notion of locking down a server is VERY REAL. In the admin/configuration category, the persistence of the configuration above and beyond the current xml is not done right now the fact that it is mixed with the creation is a weakness we are carrying over from the 2.0 days. One step at a time, when we finalize 3.x releases i.e. in a couple of weeks, I say we move on 4.0 development and the overhaul of the admin with persistence through the modelmbeans will require some tweaking of the XMBeans (I believe the current implementation lacks) where you put your own persistence in there. There are some ideas as to how to make the the persistence transparent and distributed in the MMBeans. That is the way to go and that is where we should think. The readers of the centralized file are aware of what they are monitoring. A given EJB persistence (one of the ideas) would know that it is monitoring changes in that particular configuration for that bean, and it can also come with some knowledge of that format so you don't need to go with the bare XML. That will enable you to provide defaults for example so you can override say the JCA configuration of datasources and just specify the bare minimum. I repeat that this discussion is premature. At this point we are running on empty when it comes to user feedback as the limits of the current system are not known by the users we are guessing based on our abilities, this always fails. We see them, we think about them but we need the user. Time to put it out and let the users say this would be good that would be good. Wait for more datapoint to come to our group and then we will sit down and think about JBoss4.0 configuration. We will make the new app-server generation easy to use, I will prove it. Being Admin friendly is the key to success. Don't forget that. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha |Labourey |Sent: Friday, April 26, 2002 6:30 AM |To: marc fleury; Sacha Labourey; Juha-P Lindfors; |[EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |Marc, | |I see your point and the interest of such a solution. |Nevertheless, there is another problem in fact that *currently* |favor the multiple files approach: persistent modification of |configuration. | |Currently (as of 3.0), when you want to modify some |service/bean/datasource/whatever, you take its corresponding |snippet, modify it and zou, it is re-deployed. First problem: |re-deploy should not be, in some cases, undeploy+deploy. Second |problem: everything that is in the file is re-deployed. = if you |have a single file, you redeploy everything = we tend to have |many files now because, currently, many files = fine granularity |of redeploy. | |The second category of problems is about persistence of changes. |If you say: F*ck the files, we go through JMX anyway, then any |modification made through JMX is *not* persisted (i.e. transient |modification). This is a problem, a real problem. The old solution |of keeping the old version didn't seem to work well, so it wasn't |good either. | |= IMHO, the problem is not about one vs. multiple files, it is |about granularity and persistence of changes (= granularity of |redeploy) = maybe the repository approach is a good solution. | |But *Currently*, with these issues, the multiple-file approach is |the best (only?) way to get fine-grained modification of our app server. | |Cheers, | | | Sacha | | | | | -Message d'origine- | De : marc fleury [mailto:[EMAIL PROTECTED]] | Envoye : vendredi, 26 avril 2002 15:19 | A : Sacha Labourey; Juha-P Lindfors; | [EMAIL PROTECTED] | Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | You do, this is the production file. | | There is the development files that really has their own snippets and all | and then there is the one big file for the production server |approach. I | believe we can do this in several steps | | 1- as today we recommend locking down the server configuration | once you are | done with development by merging the jboss-services into one big STATIC | jboss-services | | 2- merge ejb-jar jboss jboss-cmp in one big file so your beans are | configured in one file. There are many advantages to this | approach, namely | you get rid of 100% of the indirection. Also it is all well in one | page. We did discuss with David in January as to how to do that. | | 3- merge all of them, mbean,bean so the root tag is | jboss | mbean | bean | bla bla bla | | 4- the last gripe from the thread I am not convinced it had to do | with being | intimidated by mbean configuration files. I would have to think |about this | one, there are problems
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I totally agree with this. One of the ideas I have been kicking around is developing some production tools, which would automate the steps you describe. Part of this is david's code to merge the xml files during deployment; once they are merged and defaults unrolled, we write the complete file back out to disk. Anyway, this is a 3.1 feature and we aren't 3.0 final yet. I just can't get over the fact this guy didn't have the stones to post this to a jboss list or forum. -dain marc fleury wrote: You do, this is the production file. There is the development files that really has their own snippets and all and then there is the one big file for the production server approach. I believe we can do this in several steps 1- as today we recommend locking down the server configuration once you are done with development by merging the jboss-services into one big STATIC jboss-services 2- merge ejb-jar jboss jboss-cmp in one big file so your beans are configured in one file. There are many advantages to this approach, namely you get rid of 100% of the indirection. Also it is all well in one page. We did discuss with David in January as to how to do that. 3- merge all of them, mbean,bean so the root tag is jboss mbean bean bla bla bla 4- the last gripe from the thread I am not convinced it had to do with being intimidated by mbean configuration files. I would have to think about this one, there are problems with separating creation and configuration (but it should be done imho) where the creation references a configuration by name, then the XML syntax usage should be simplified as much as possible, avoid XML verbosity, nobody likes it. 5- gui? pf it would need to be a JMX gui in our case, why not, but everybody talks about these and no-one does jack. marcf |-Original Message- |From: Sacha Labourey [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 5:55 AM |To: marc fleury; Sacha Labourey; Juha-P Lindfors; |[EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |Well, it really depends IMHO. Would you really want to have |security information (users, groups, ...) in the same file as the |services (jboss-services.xml) ? I am not sure... | | -Message d'origine- | De : marc fleury [mailto:[EMAIL PROTECTED]] | Envoye : vendredi, 26 avril 2002 14:53 | A : Sacha Labourey; Juha-P Lindfors; | [EMAIL PROTECTED] | Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | I totally agree with the article, I believe we should merge our | configuration files today, and get rid of the unreadable XML, ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Instead of Gnome how about a Java Application--Desktop. And have the application GUI centered around Naked Objects(www.nakedobjects.org) Each pull-down window would be the front-end of a JBoss config file. Dave Smith [EMAIL PROTECTED] 04/26/02 08:23AM The problem is not the configuration files its the interface. What you really need is a gnome control panel type interface which would allow you to configure and manage your jboss enviroment. This is bigest problem with open source projects, no-one likes writting front ends, it's boring and not sexy. Don't put the configs in 1 file, 20 piles of shit or 1 big pile of shit it is still a pile of shit. On Fri, 2002-04-26 at 08:54, Sacha Labourey wrote: Well, it really depends IMHO. Would you really want to have security information (users, groups, ...) in the same file as the services (jboss-services.xml) ? I am not sure... -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoye : vendredi, 26 avril 2002 14:53 A : Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? I totally agree with the article, I believe we should merge our configuration files today, and get rid of the unreadable XML, ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
1. I'm hoping to work on the one file for ejb config very soon as soon as testsuite errors = 0 and the jca is marginally more stable (i.e. I quit changing it, it seems to work OK). 2. I think Sacha's point about granularity and location of changes and persistence is REALLY IMPORTANT! I've made a couple of suggestions about how mbean persistence relates to the files, only Jason responded. Basically I think to use mbean persistence we have to think of the mbean server like a database that remembers its current state, even over shutdown/restart. Then the xml config files need to be viewed as update scripts to this database. I don't really know if this is a good idea, it is certainly a different way of thinking than we have now, but I think it is worth considering and experimenting with. thanks david jencks On 2002.04.26 09:29:36 -0400 Sacha Labourey wrote: Marc, I see your point and the interest of such a solution. Nevertheless, there is another problem in fact that *currently* favor the multiple files approach: persistent modification of configuration. Currently (as of 3.0), when you want to modify some service/bean/datasource/whatever, you take its corresponding snippet, modify it and zou, it is re-deployed. First problem: re-deploy should not be, in some cases, undeploy+deploy. Second problem: everything that is in the file is re-deployed. = if you have a single file, you redeploy everything = we tend to have many files now because, currently, many files = fine granularity of redeploy. The second category of problems is about persistence of changes. If you say: F*ck the files, we go through JMX anyway, then any modification made through JMX is *not* persisted (i.e. transient modification). This is a problem, a real problem. The old solution of keeping the old version didn't seem to work well, so it wasn't good either. = IMHO, the problem is not about one vs. multiple files, it is about granularity and persistence of changes (= granularity of redeploy) = maybe the repository approach is a good solution. But *Currently*, with these issues, the multiple-file approach is the best (only?) way to get fine-grained modification of our app server. Cheers, Sacha -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoye : vendredi, 26 avril 2002 15:19 A : Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? You do, this is the production file. There is the development files that really has their own snippets and all and then there is the one big file for the production server approach. I believe we can do this in several steps 1- as today we recommend locking down the server configuration once you are done with development by merging the jboss-services into one big STATIC jboss-services 2- merge ejb-jar jboss jboss-cmp in one big file so your beans are configured in one file. There are many advantages to this approach, namely you get rid of 100% of the indirection. Also it is all well in one page. We did discuss with David in January as to how to do that. 3- merge all of them, mbean,bean so the root tag is jboss mbean bean bla bla bla 4- the last gripe from the thread I am not convinced it had to do with being intimidated by mbean configuration files. I would have to think about this one, there are problems with separating creation and configuration (but it should be done imho) where the creation references a configuration by name, then the XML syntax usage should be simplified as much as possible, avoid XML verbosity, nobody likes it. 5- gui? pf it would need to be a JMX gui in our case, why not, but everybody talks about these and no-one does jack. marcf |-Original Message- |From: Sacha Labourey [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 5:55 AM |To: marc fleury; Sacha Labourey; Juha-P Lindfors; |[EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |Well, it really depends IMHO. Would you really want to have |security information (users, groups, ...) in the same file as the |services (jboss-services.xml) ? I am not sure... | | -Message d'origine- | De : marc fleury [mailto:[EMAIL PROTECTED]] | Envoye : vendredi, 26 avril 2002 14:53 | A : Sacha Labourey; Juha-P Lindfors; | [EMAIL PROTECTED] | Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | I totally agree with the article, I believe we should merge our | configuration files today, and get rid of the unreadable XML, ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jboss tmp directory
How do I get a hold of the Jboss tmp directory (or any other default directory) programmatically? ie. something like ServerConfigLocator.locate().getServerTempDir() - it seems that ServerConfigLocator doesn't exist in 3.0. Thanks, Ken * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=14099 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
|2. I think Sacha's point about granularity and location of changes and |persistence is REALLY IMPORTANT! I've made a couple of suggestions |about how mbean persistence relates to the files, only Jason responded. juha is the man for the mmbean persistence, sacha will be lead on this for 4.0 :) we are aware of the problem let's hold our horses for now. Soon enough (like in a month or so). marcf |Basically I think to use mbean persistence we have to think of the mbean |server like a database that remembers its current state, even over |shutdown/restart. Then the xml config files need to be viewed as update |scripts to this database. I don't really know if this is a good idea, it |is certainly a different way of thinking than we have now, but I think it |is worth considering and experimenting with. | |thanks |david jencks | | |On 2002.04.26 09:29:36 -0400 Sacha Labourey wrote: | Marc, | | I see your point and the interest of such a solution. Nevertheless, there | is another problem in fact that *currently* favor the multiple files | approach: persistent modification of configuration. | | Currently (as of 3.0), when you want to modify some | service/bean/datasource/whatever, you take its corresponding snippet, | modify it and zou, it is re-deployed. First problem: re-deploy should not | be, in some cases, undeploy+deploy. Second problem: everything that is in | the file is re-deployed. = if you have a single file, you redeploy | everything = we tend to have many files now because, currently, many | files = fine granularity of redeploy. | | The second category of problems is about persistence of changes. If you | say: F*ck the files, we go through JMX anyway, then any modification | made through JMX is *not* persisted (i.e. transient modification). This | is a problem, a real problem. The old solution of keeping the old version | didn't seem to work well, so it wasn't good either. | | = IMHO, the problem is not about one vs. multiple files, it is about | granularity and persistence of changes (= granularity of redeploy) = | maybe the repository approach is a good solution. | | But *Currently*, with these issues, the multiple-file approach is the | best (only?) way to get fine-grained modification of our app server. | | Cheers, | | | Sacha | | | | | -Message d'origine- | De : marc fleury [mailto:[EMAIL PROTECTED]] | Envoye : vendredi, 26 avril 2002 15:19 | A : Sacha Labourey; Juha-P Lindfors; | [EMAIL PROTECTED] | Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | You do, this is the production file. | | There is the development files that really has their own snippets and | all | and then there is the one big file for the production server approach. | I | believe we can do this in several steps | | 1- as today we recommend locking down the server configuration | once you are | done with development by merging the jboss-services into one big STATIC | jboss-services | | 2- merge ejb-jar jboss jboss-cmp in one big file so your beans are | configured in one file. There are many advantages to this | approach, namely | you get rid of 100% of the indirection. Also it is all well in one | page. We did discuss with David in January as to how to do that. | | 3- merge all of them, mbean,bean so the root tag is | jboss | mbean | bean | bla bla bla | | 4- the last gripe from the thread I am not convinced it had to do | with being | intimidated by mbean configuration files. I would have to think about | this | one, there are problems with separating creation and configuration (but | it | should be done imho) where the creation references a | configuration by name, | then the XML syntax usage should be simplified as much as possible, | avoid | XML verbosity, nobody likes it. | | 5- gui? pf it would need to be a JMX gui in our case, why not, but | everybody talks about these and no-one does jack. | | | marcf | |-Original Message- | |From: Sacha Labourey [mailto:[EMAIL PROTECTED]] | |Sent: Friday, April 26, 2002 5:55 AM | |To: marc fleury; Sacha Labourey; Juha-P Lindfors; | |[EMAIL PROTECTED] | |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise | solution? | | | | | |Well, it really depends IMHO. Would you really want to have | |security information (users, groups, ...) in the same file as the | |services (jboss-services.xml) ? I am not sure... | | | | -Message d'origine- | | De : marc fleury [mailto:[EMAIL PROTECTED]] | | Envoye : vendredi, 26 avril 2002 14:53 | | A : Sacha Labourey; Juha-P Lindfors; | | [EMAIL PROTECTED] | | Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise | solution? | | | | | | I totally agree with the article, I believe we should merge our | | configuration files today, and get rid of the unreadable XML, | | | | | ___ | Jboss-development mailing list | [EMAIL
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
On Fri, 26 Apr 2002, marc fleury wrote: One step at a time, when we finalize 3.x releases i.e. in a couple of weeks, I say we move on 4.0 development and the overhaul of the admin with persistence through the modelmbeans will require some tweaking of the XMBeans (I believe the current implementation lacks) where you put your own umm, we dont really have any implementation for persistence at the moment so yes it does lack :) -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
interesting, let's see what becomes real. I like the idea of the MS console plugin marcf |-Original Message- |From: Christian Riege [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 7:43 AM |To: marc fleury |Cc: Sacha Labourey; Juha-P Lindfors; JBoss Dev list |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |hi, | | 5- gui? pf it would need to be a JMX gui in our case, why not, but | everybody talks about these and no-one does jack. | |i think what Dr. Jung mentioned @ JBossOne would be a killer: expose the |MBeans via SOAP and construct a Microsoft Management Console Plugin to |configure/maintain JBoss from that beast. | |other than that, my 2 (albeit euro) cents on the subject of the config |files: | |i don't give one cent on how the config file looks like (i.e. XML, |key=value, ...) AS LONG AS I CAN EDIT IT WITH MY TEXT-EDITOR OF CHOICE. | |consolidation/deconsolidation of the configuration has its own pros and |cons. personally i would like to have both available: small files for |development/testing purposes (un-deploy of an MBean by simply issuing |'mv mbean.jar ../nodepoy') and one huge file for locking down my |production servers. | |i *think* you can achieve both by using several XML files which can be |merged (at the users option, with a *simple* command) into one big XML |file: develop/test with the small ones until you're happy. hit the |lockdown config button. get a large file which is the sum of the small |ones. xml namespaces might come in handy here?! | |rgds, | christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
AW: [JBoss-dev] [JL] Is it time for a new enterprise solution?
He, he. Volunteers? In the meantime, I heard from my colleagues who had actually done some MMC programming that it would be a real nightmare indeed :-( So much for expectations. Wonder if VS.net makes it more handy ... CGJ -Ursprüngliche Nachricht- Von: marc fleury [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 26. April 2002 16:53 An: Christian Riege Cc: Sacha Labourey; Juha-P Lindfors; JBoss Dev list Betreff: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? interesting, let's see what becomes real. I like the idea of the MS console plugin marcf |-Original Message- |From: Christian Riege [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 7:43 AM |To: marc fleury |Cc: Sacha Labourey; Juha-P Lindfors; JBoss Dev list |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |hi, | | 5- gui? pf it would need to be a JMX gui in our case, why not, | but everybody talks about these and no-one does jack. | |i think what Dr. Jung mentioned @ JBossOne would be a killer: expose |the MBeans via SOAP and construct a Microsoft Management Console Plugin |to configure/maintain JBoss from that beast. | |other than that, my 2 (albeit euro) cents on the subject of the config |files: | |i don't give one cent on how the config file looks like (i.e. XML, |key=value, ...) AS LONG AS I CAN EDIT IT WITH MY TEXT-EDITOR OF CHOICE. | |consolidation/deconsolidation of the configuration has its own pros and |cons. personally i would like to have both available: small files for |development/testing purposes (un-deploy of an MBean by simply issuing |'mv mbean.jar ../nodepoy') and one huge file for locking down my |production servers. | |i *think* you can achieve both by using several XML files which can be |merged (at the users option, with a *simple* command) into one big XML |file: develop/test with the small ones until you're happy. hit the |lockdown config button. get a large file which is the sum of the |small ones. xml namespaces might come in handy here?! | |rgds, | christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 528 votes and 4th place in the TOP25!
Title: Nachricht This is theregular, non-automizedbug-voting reminder for those of you who haven´t pulled up their asses yet to visit JDC at: http://developer.java.sun.com/developer/bugParade/bugs/4670071.html (all others, great effort, we will make it number #1). FYI: ThisRFE tries to convince SUN to take one of these nasty modifiers fromthe java.lang.ClassLoader.loadClassInternal(String) method which would allow us to remove a whole lot of ugly and imperformant (though, I must say, genius!) deadlock-avoiding code fromsome of the core classes of JBoss3.x (and think about even more evil classloading models for JBoss4 ;-) CGJ
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
The view on the configuration should be task-oriented, not file-oriented. It's so easy to understand why a GUI is necessary. And why XML is necessary. Having to argue about these things makes me feel desolate. Georg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Joseph Olson Sent: Friday, April 26, 2002 15:53 To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? Instead of Gnome how about a Java Application--Desktop. And have the application GUI centered around Naked Objects(www.nakedobjects.org) Each pull-down window would be the front-end of a JBoss config file. Dave Smith [EMAIL PROTECTED] 04/26/02 08:23AM The problem is not the configuration files its the interface. What you really need is a gnome control panel type interface which would allow you to configure and manage your jboss enviroment. This is bigest problem with open source projects, no-one likes writting front ends, it's boring and not sexy. Don't put the configs in 1 file, 20 piles of shit or 1 big pile of shit it is still a pile of shit. On Fri, 2002-04-26 at 08:54, Sacha Labourey wrote: Well, it really depends IMHO. Would you really want to have security information (users, groups, ...) in the same file as the services (jboss-services.xml) ? I am not sure... -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoye : vendredi, 26 avril 2002 14:53 A : Sacha Labourey; Juha-P Lindfors; [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? I totally agree with the article, I believe we should merge our configuration files today, and get rid of the unreadable XML, ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
|It's so easy to understand why a GUI is necessary. And why XML is |necessary. |Having to argue about these things makes me feel desolate. don't feel desolate, code marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I have been waiting for that one ;-) Seriously, my day-time job does not leave much room for coding anything else. This leaves me of course open to all kinds of attacks... especially being ignored. Georg -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 18:49 To: [EMAIL PROTECTED]; 'Joseph Olson'; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? |It's so easy to understand why a GUI is necessary. And why XML is |necessary. Having to argue about these things makes me feel desolate. don't feel desolate, code marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-549163 ] Wrong verifier warning for home method
Bugs item #549163, was opened at 2002-04-26 18:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549163group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong verifier warning for home method Initial Comment: When deploying an EB with a home method, the verifier says: 16:11:57,784 INFO [EJBDeployer] Bean : MaintenanceEB Method : public abstract void removeAll(Collection) throws RemoteException, RemoveException Section: 12.2.9 Warning: A home method declared in the home interface must not return the entity beans remote interface. As can be seen, the method does not return anything, how could it return the entity beans remote interface? Georg -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549163group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Had some trouble building JBoss from source
When I followed the build instruction in the guide, my build command was failing with: build/build.sh Searching for build.xml ... Buildfile: /u2/src/jboss/jboss-all/build/build.xml BUILD FAILED Error reading project file Total time: 1 second Sombody raised this issue back on December 13th,2001 but it went unanswered. Anyway, I solved my problem, it was due to my having an existing ~/.antrc configuration file that is setting ANT_HOME. Seems like the following DOCTYPE in build.xml was the cause of the problem when using my version of ant pointed by ANT_HOME. !DOCTYPE project [ !ENTITY buildmagic SYSTEM resource://org/jboss/tools/buildmagic/common.xml] Without my .antrc, it seems the build tool was able to pick the files that are in the jboss-all/tools directory instead of my ant installation. Hopefully this will help others, and maybe someone has a better suggestion than renaming my .antrc file when building Jboss (or playing with $HOME). Maybe the build.sh script (or the local ant shell script) could be modified to be resilient to this problem. -- regards * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=14129 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Clustering statefulSessionHome.remove did not fail
This unit test is the last clustering test that continues to fail regularly. Please look into this and fix it. statefulSessionHome.remove did not fail junit.framework.AssertionFailedError: statefulSessionHome.remove did not fail at junit.framework.Assert.fail(Assert.java:51) at org.jboss.test.testbean.test.BeanUnitTestCase.testStatefulBean(BeanUnitTestC ase.java:341) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:166) at junit.framework.TestCase.runBare(TestCase.java:140) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:131) at junit.framework.TestSuite.runTest(TestSuite.java:173) at junit.framework.TestSuite.run(TestSuite.java:168) at junit.framework.TestSuite.runTest(TestSuite.java:173) at junit.framework.TestSuite.run(TestSuite.java:168) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRu nner.java:231) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestR unner.java:409) Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-549163 ] Wrong verifier warning for home method
Bugs item #549163, was opened at 2002-04-26 18:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549163group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong verifier warning for home method Initial Comment: When deploying an EB with a home method, the verifier says: 16:11:57,784 INFO [EJBDeployer] Bean : MaintenanceEB Method : public abstract void removeAll(Collection) throws RemoteException, RemoveException Section: 12.2.9 Warning: A home method declared in the home interface must not return the entity beans remote interface. As can be seen, the method does not return anything, how could it return the entity beans remote interface? Georg -- Comment By: Georg Schmid (giorgio42) Date: 2002-04-26 18:37 Message: Logged In: YES user_id=437570 Ehmm, forgot: JBoss 3.1.0alpha, Solaris and WinNT. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549163group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Getting EJBException in JBoss
Hi All I am getting EJB exception in my application which is running in JBoss-2.4.4_Tomcat-3.2.3 and mysql as database. I am not able to figure out the problem. Can anyone pls give me some idea regarding this exception. Thanks a lot in advance Mahesh [2002-04-26 01:06:30,851; ConfigurationAction]Thread-33 request user type: Client [2002-04-26 01:06:30,851; ConfigurationAction]Thread-33 supplier_user: SUPPLIER [2002-04-26 01:06:30,851; ConfigurationAction]Thread-33 Entering selectSupplier method [2002-04-26 01:06:30,851; ConfigurationManagerSB]Thread-33 Entering getSupplierList method [2002-04-26 01:06:30,853; JAWSPersistenceManager]Thread-33 findByCompanyBySort command executing: SELECT SUPPLIER_COMPANIES.COMPANY_ID, COMPANY_NAME FROM SUPPLIER_COMPANIES where COMPANY_ID is not null ORDER BY COMPANY_NAME ASC [2002-04-26 01:06:30,873; Default]Thread-33 java.rmi.ServerException: Exception occurred; nested exception is: javax.ejb.EJBException: null Embedded Exception null [2002-04-26 01:06:30,873; Default]Thread-33 javax.ejb.EJBException: null Embedded Exception null [2002-04-26 01:06:30,873; Default]Thread-33 at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Stateles sSessionContainer.java:553) [2002-04-26 01:06:30,873; Default]Thread-33 [2002-04-26 01:06:30,873; Default]Thread-33 at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSe ssionInstanceInterceptor.java:82) [2002-04-26 01:06:30,874; Default]Thread-33 [2002-04-26 01:06:30,874; Default]Thread-33 at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:138) [2002-04-26 01:06:30,874; Default]Thread-33 [2002-04-26 01:06:30,874; Default]Thread-33 at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT. java:478) [2002-04-26 01:06:30,874; Default]Thread-33 [2002-04-26 01:06:30,874; Default]Thread-33 at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:100) [2002-04-26 01:06:30,874; Default]Thread-33 [2002-04-26 01:06:30,874; Default]Thread-33 at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:12 7) [2002-04-26 01:06:30,874; Default]Thread-33 [2002-04-26 01:06:30,874; Default]Thread-33 at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170) [2002-04-26 01:06:30,874; Default]Thread-33 [2002-04-26 01:06:30,874; Default]Thread-33 at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.jav a:286) [2002-04-26 01:06:30,874; Default]Thread-33 [2002-04-26 01:06:30,875; Default]Thread-33 at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI nvoker.java:504) [2002-04-26 01:06:30,875; Default]Thread-33 [2002-04-26 01:06:30,875; Default]Thread-33 at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer(GenericPr oxy.java:335) [2002-04-26 01:06:30,875; Default]Thread-33 [2002-04-26 01:06:30,875; Default]Thread-33 at org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy.invoke(Stateless SessionProxy.java:123) [2002-04-26 01:06:30,875; Default]Thread-33 [2002-04-26 01:06:30,875; Default]Thread-33 at $Proxy51.getSupplierList(Unknown Source) [2002-04-26 01:06:30,875; Default]Thread-33 [2002-04-26 01:06:30,875; Default]Thread-33 at com.zeborg.labor.action.configuration.ConfigurationAction.selectSupplier(Con figurationAction.java:1244) [2002-04-26 01:06:30,875; Default]Thread-33 [2002-04-26 01:06:30,875; Default]Thread-33 at com.zeborg.labor.action.configuration.ConfigurationAction.selectSupplierToCo nfigure(ConfigurationAction.java:1271) [2002-04-26 01:06:30,875; Default]Thread-33 [2002-04-26 01:06:30,875; Default]Thread-33 at java.lang.reflect.Method.invoke(Native Method) [2002-04-26 01:06:30,875; Default]Thread-33 [2002-04-26 01:06:30,876; Default]Thread-33 at com.zeborg.labor.action.MethodDispatchAction.perform(MethodDispatchAction.ja va:183) [2002-04-26 01:06:30,876; Default]Thread-33 [2002-04-26 01:06:30,876; Default]Thread-33 at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.ja va:1720) [2002-04-26 01:06:30,876; Default]Thread-33 [2002-04-26 01:06:30,876; Default]Thread-33 at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1519) [2002-04-26 01:06:30,876; Default]Thread-33 [2002-04-26 01:06:30,876; Default]Thread-33 at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:487) [2002-04-26 01:06:30,876; Default]Thread-33 [2002-04-26 01:06:30,876; Default]Thread-33 at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) [2002-04-26 01:06:30,876; Default]Thread-33 [2002-04-26 01:06:30,876; Default]Thread-33 at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) [2002-04-26 01:06:30,876; Default]Thread-33 [2002-04-26 01:06:30,876; Default]Thread-33 at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:405) [2002-04-26 01:06:30,876; Default]Thread-33 [2002-04-26 01:06:30,877; Default]Thread-33 at
[JBoss-dev] [ jboss-Bugs-549163 ] Wrong verifier warning for home method
Bugs item #549163, was opened at 2002-04-26 12:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549163group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Jay Walters (jwalters) Summary: Wrong verifier warning for home method Initial Comment: When deploying an EB with a home method, the verifier says: 16:11:57,784 INFO [EJBDeployer] Bean : MaintenanceEB Method : public abstract void removeAll(Collection) throws RemoteException, RemoveException Section: 12.2.9 Warning: A home method declared in the home interface must not return the entity beans remote interface. As can be seen, the method does not return anything, how could it return the entity beans remote interface? Georg -- Comment By: Jay Walters (jwalters) Date: 2002-04-26 15:32 Message: Logged In: YES user_id=183794 Seems the verifier isn't allowing for that case. I will take a look at it. -- Comment By: Georg Schmid (giorgio42) Date: 2002-04-26 12:37 Message: Logged In: YES user_id=437570 Ehmm, forgot: JBoss 3.1.0alpha, Solaris and WinNT. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549163group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Hi George The view on the configuration should be task-oriented, not file-oriented. Do you have an example for that ? I know BEA WL 5 and IBM WebSphere 3.5 and both did not provide configuration on their UI. It's so easy to understand why a GUI is necessary. And why XML is necessary. When I was working on BEA WebLogic (yes, I was) they had a usable UI but I still configured the server through the file. Mostly because the heavy configuration stuff is not added to the UI. A UI makes sense to discover all the services and deployments and get statistics out of it which JSR-77 should do so. But I am convinced that configuring a server is advanced stuff and should not be made too easy otherwise it will break all the time. An application server is not a volatile system with respect to configuration. Have fun - Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] (no subject)
I am contacting you with the hope that you will be of great assistance to me, I currently have within my reach the sum of 25million US. dollars cash which I intend to use for investment purposes in your company. This money came as a result of a payback contract deal between my husband and a Russain firm in our country's multi-billion dollar Ajaokuta steel plant. The Russain partners returned my husbands share being the above sum after his death. Presently, the new civilian Government has intensified their probe into my husbands financial resources which has led to the freezing of all our accounts, local and foreign, the revoking of all our business licences and the arrest of my first son. In veiw of this I acted very fast to withdraw this money from one of our finance houses before it was closed down. I have deposited the money in a security company with the help of very loyal officials of my late husband. No record is know about this fund by the government because there is no decumentation showing that we received such funds. Due to the current situation in the country and government attitude to my family, I cannot make use of this money within, thus I seek your help in transfering this fund out of the sub African region. Bearing in mind that you may assist me, I have decided to part with 20% of the total sum. Your URGENT response is needed. All correspondance must be through email addresses:[EMAIL PROTECTED] for confidentiality. All correspondence is for the attention of my counsel:Barrister Desmond Opa. Please include your personal phone and Fax number. Regards, JOACHIM SAVIMBE. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I am working on web based management application, at this point it only supports the currently implemented parts of the JSR 77 spec that exist in JBoss, but I envision this to be expanded to support all service related management offered by the JBoss platform. If there is sufficient interest, I can post this once I fix a few minor bugs * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=14061 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] (no subject)
It's truly funny that dumb spam like this would show up on a Sourceforge list. -Original Message- From: joachim savimbi [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 1:00 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] (no subject) I am contacting you with the hope that you will be of great assistance to me, I currently have within my reach the sum of 25million US. dollars cash which I intend to use for investment purposes in your company. This money came as a result of a payback contract deal between my husband and a Russain firm in our country's multi-billion dollar Ajaokuta steel plant. The Russain partners returned my husbands share being the above sum after his death. Presently, the new civilian Government has intensified their probe into my husbands financial resources which has led to the freezing of all our accounts, local and foreign, the revoking of all our business licences and the arrest of my first son. In veiw of this I acted very fast to withdraw this money from one of our finance houses before it was closed down. I have deposited the money in a security company with the help of very loyal officials of my late husband. No record is know about this fund by the government because there is no decumentation showing that we received such funds. Due to the current situation in the country and government attitude to my family, I cannot make use of this money within, thus I seek your help in transfering this fund out of the sub African region. Bearing in mind that you may assist me, I have decided to part with 20% of the total sum. Your URGENT response is needed. All correspondance must be through email addresses:[EMAIL PROTECTED] for confidentiality. All correspondence is for the attention of my counsel:Barrister Desmond Opa. Please include your personal phone and Fax number. Regards, JOACHIM SAVIMBE. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
you bet post it! marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |McLaughlin |Sent: Friday, April 26, 2002 1:03 PM |To: [EMAIL PROTECTED] |Subject: Re: RE: [JBoss-dev] [JL] Is it time for a new enterprise |solution? | | |I am working on web based management application, at this point it |only supports the currently implemented parts of the JSR 77 spec |that exist in JBoss, but I envision this to be expanded to support |all service related management offered by the JBoss platform. If |there is sufficient interest, I can post this once I fix a few minor bugs |* * * | |View thread online: |http://jboss.org/forums/thread.jsp?forum=66thread=14061 | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Clustering statefulSessionHome.remove did not fail
It is now fixed. In fact, I thought it was a false positive, but it wasn't! it seems to mean that tests *are* usefull... ;) -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : vendredi, 26 avril 2002 20:12 À : [EMAIL PROTECTED] Objet : [JBoss-dev] Clustering statefulSessionHome.remove did not fail This unit test is the last clustering test that continues to fail regularly. Please look into this and fix it. statefulSessionHome.remove did not fail ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Andreas Schaefer wrote: Hi George The view on the configuration should be task-oriented, not file-oriented. Do you have an example for that ? I know BEA WL 5 and IBM WebSphere 3.5 and both did not provide configuration on their UI. Both now provide configuration UIs. It's so easy to understand why a GUI is necessary. And why XML is necessary. When I was working on BEA WebLogic (yes, I was) they had a usable UI but I still configured the server through the file. Mostly because the heavy configuration stuff is not added to the UI. WL 5 had a UI whereby you could change things, but did not persist the changes, IIRC. A UI makes sense to discover all the services and deployments and get statistics out of it which JSR-77 should do so. But I am convinced that configuring a server is advanced stuff and should not be made too easy otherwise it will break all the time. An application server is not a volatile system with respect to configuration. Which is a very good reason to have the configuration secured, but not necessarily a good reason to not have a GUI. Do we still provide the (unsecured) JMX web interface as default, as we did in 2.4.x? I don't necessarily see myself as being a big user of a GUI, but I do understand why people really want one - it will cut down the learning curve, and we are getting to the point where some of the people using JBoss are people who program computers for a living, not necessarily because they like it! Also, in a large organization, the people charged with management of servers are not generally programmers persay - they'll knock together a perl script, but a sysadmin who knows Java is rare. A normal sysadmin will look at the xml in JBoss configuration files and suddenly have a fond rememberance of the last time he had to 'correct' a make file for some daemon on one of his boxes. And that's on the Unix side of things - think about NT administrators! Have fun - Andy Always! danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
marc fleury wrote: Sacha, this is configuration for JBoss4.0. The fact is that for *production* the one file is good. For actually administering and configuring a server the many files is better, yes, but they are different world, the notion of locking down a server is VERY REAL. Sure. I do that by setting permissions of the config and deploy directories such that only the JBoss user can do anything (including read). What good does having one big honking file do here? I agree that it does no harm, but I don't see how it 'locks down' the server. In the admin/configuration category, the persistence of the configuration above and beyond the current xml is not done right now the fact that it is mixed with the creation is a weakness we are carrying over from the 2.0 days. Right, to really fix that will have to be a 4.0 issue. Once that works, JBoss will be administrable from whatever can use JMX - JSR 88 based tools, SNMP management tools, etc. my .02$ danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Clustering statefulSessionHome.remove did not fail
IMNSHO the tests and Jason's build system are the only things keeping us from falling into total chaos. david On 2002.04.26 16:30:26 -0400 Sacha Labourey wrote: It is now fixed. In fact, I thought it was a false positive, but it wasn't! it seems to mean that tests *are* usefull... ;) -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : vendredi, 26 avril 2002 20:12 À : [EMAIL PROTECTED] Objet : [JBoss-dev] Clustering statefulSessionHome.remove did not fail This unit test is the last clustering test that continues to fail regularly. Please look into this and fix it. statefulSessionHome.remove did not fail ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-549272 ] misspelled method name
Bugs item #549272, was opened at 2002-04-26 23:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549272group_id=22866 Category: JBossMail Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Harald Øygard (haroyg) Assigned to: Nobody/Anonymous (nobody) Summary: misspelled method name Initial Comment: The method called destoryService() in org.jboss.mail.MailService should read destroyService () to override the extended method in org.jboss.system.ServiceMBeanSupport. File: contrib\varia\src\main\org\jboss\mailMailService.java Revision: 1.7 Line: 233 -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549272group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
by locking down I mean not only one file with restricted access but one central place with full configuration. Many files is interesting for independently configuring parts, locking down means the server configuration is fixed, locked, no messing with upgrade here and there in many files. The thing is in one place, the server configuration is locked down. Having one file makes it simple to see/analyze/replicate/distribute. It was a very popular feature of BEA in production, one central place. Easy. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of danch |Sent: Friday, April 26, 2002 2:03 PM |To: marc fleury |Cc: Sacha Labourey; Juha-P Lindfors; |[EMAIL PROTECTED] |Subject: Re: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |marc fleury wrote: | | Sacha, | | this is configuration for JBoss4.0. | | The fact is that for *production* the one file is good. | | For actually administering and configuring a server the many files is | better, yes, but they are different world, the notion of locking down a | server is VERY REAL. | | |Sure. I do that by setting permissions of the config and deploy |directories such that only the JBoss user can do anything (including |read). What good does having one big honking file do here? I agree |that it does no harm, but I don't see how it 'locks down' the server. | | | In the admin/configuration category, the persistence | of the configuration above and beyond the current xml is not |done right now | the fact that it is mixed with the creation is a weakness we are carrying | over from the 2.0 days. | | |Right, to really fix that will have to be a 4.0 issue. Once that |works, JBoss will be administrable from whatever can use JMX - JSR 88 |based tools, SNMP management tools, etc. | |my .02$ |danch | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I think this is a very bad idea... Yet if it comes down to this then we will need to implement some xslt stuff into the build system so that each module can contain the snippets of xml that get merged into the huge monolithic config file otherwise managing the configuration when running a build is going to be a royal mess. --jason Quoting marc fleury [EMAIL PROTECTED]: I totally agree with the article, I believe we should merge our configuration files today, and get rid of the unreadable XML, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha |Labourey |Sent: Friday, April 26, 2002 1:38 AM |To: Juha-P Lindfors; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |Oh yeahh!!! That would be so cool!!! Only one config file, and one |bigg monolithic application server that you can configure in |this only big file! That would be so cool!!! And if we could merge |the database configuration file, OS configuration files and Doom's |configuration file in one big file, that would be *really* cool. | |humpf... | | -Message d'origine- | De : [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]De la part de | Juha-P Lindfors | Envoye : vendredi, 26 avril 2002 08:05 | A : [EMAIL PROTECTED] | Objet : [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | | Critique on JBoss configuration. | | http://www.javalobby.org/thread.jsp?forum=61thread=3254 | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Data validation in EJB
Hi Marc should really be done with client interceptors, really. It is yet another great application for these puppies, from clustering to ejb behavior to datavalidation and transactional support and client caching, the client interceptors are going to spark a small revolution in superserver design. Not quite sure. As long as you check if some values are within some limits that will work but when you checking if this record does not already exists (other unique indexes beside the PK like SSN etc.) you have to call the server either way and then when you have more than one call you will spoil more time than you win. Also how you want to create portable applications and how to deal with security issues except you are going to recheck the data on the server side as well (I don't think that a concerned application server manager what to bet the data integrity on a client side interceptor). Have fun - Andy ATTENTION JBoss Users: - Addictive when mixed with Java !! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Clustering statefulSessionHome.remove did not fail
Every time I think about it, it reminds me of the titanic movie where there is this guy with a gun, shooting and screaming ORDER! ORDER I SAY!. Maybe the image isn't perfect, since JBoss certainly isn't the Titanic, our competition is, but that sense of sanity among chaos is what I mean. It's also normal that we have them, as there are many many contributions and we will grow a lot soon as we move to 3.1 and 4.0 so this must be re-enforced. The order of the Defenders is the ultimate one, work on the meta-system, and bring meta-order to the order less. It's self arranging once the system is there? One day there will be a *real* theoritical analysis of how Open Source organizes work. I believe there are stability points. But today we are winging it. It works, I'm just not sure why... passion, professionalism, youthfull enthusiasm, genius, creative anarchism, paternalism, idealism, fascism, OSS just seems to work. Beats me, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Friday, April 26, 2002 2:08 PM |To: Sacha Labourey |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Clustering statefulSessionHome.remove did not |fail | | |IMNSHO the tests and Jason's build system are the only things keeping us |from falling into total chaos. | |david | |On 2002.04.26 16:30:26 -0400 Sacha Labourey wrote: | It is now fixed. In fact, I thought it was a false positive, but it | wasn't! it seems to mean that tests *are* usefull... ;) | | -Message d'origine- | De : [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]De la part de | Scott M Stark | Envoyé : vendredi, 26 avril 2002 20:12 | À : [EMAIL PROTECTED] | Objet : [JBoss-dev] Clustering statefulSessionHome.remove did not fail | | | This unit test is the last clustering test that continues to fail | regularly. Please look into this and fix it. | | statefulSessionHome.remove did not fail | | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
The fact is that for *production* the one file is good. This is your assumption... not always the case... actuall should not matter too much if the folks running thr show know what they are doing. Further more the many file config now can be turned into a single file config if desired. I think this is a very weak argument. I repeat that this discussion is premature. At this point we are running on empty when it comes to user feedback as the limits of the current system are not known by the users we are guessing based on our abilities, this always fails. Yes, glad to hear toy say this. BTW, if we abstract the configuration completly into an isolated service which deals with an config API model, then we can implement any fashion of configuration... single file, multi file, database whatever. Then let the user pick what the end method of persistence is. --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 27-April-2002
Number of tests run: 578 Successful tests: 566 Errors:1 Failures: 11 [time of test: 27 April 2002 0:55 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20010626 for details of this test. See http://lubega.com for general test information. 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Had some trouble building JBoss from source
Perhaps we should not include this file... I will consider this when I get to the next round of build system fixes/mods/changes. --jason Gerald Hewes wrote: When I followed the build instruction in the guide, my build command was failing with: build/build.sh Searching for build.xml ... Buildfile: /u2/src/jboss/jboss-all/build/build.xml BUILD FAILED Error reading project file Total time: 1 second Sombody raised this issue back on December 13th,2001 but it went unanswered. Anyway, I solved my problem, it was due to my having an existing ~/.antrc configuration file that is setting ANT_HOME. Seems like the following DOCTYPE in build.xml was the cause of the problem when using my version of ant pointed by ANT_HOME. !DOCTYPE project [ !ENTITY buildmagic SYSTEM resource://org/jboss/tools/buildmagic/common.xml] Without my .antrc, it seems the build tool was able to pick the files that are in the jboss-all/tools directory instead of my ant installation. Hopefully this will help others, and maybe someone has a better suggestion than renaming my .antrc file when building Jboss (or playing with $HOME). Maybe the build.sh script (or the local ant shell script) could be modified to be resilient to this problem. -- regards * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=14129 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Data validation in EJB
should really be done with client interceptors, really. It is yet another great application for these puppies, from clustering to ejb behavior to datavalidation and transactional support and client caching, the client interceptors are going to spark a small revolution in superserver design. Just thought I would let you know. marcf x Marc Fleury, Ph.D President JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 27-April-2002
Number of tests run: 585 Successful tests: 574 Errors:0 Failures: 11 [time of test: 27 April 2002 1:43 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20020124 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20020124 for details of this test. See http://lubega.com for general test information. 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Clustering statefulSessionHome.remove did not fail
on 27-04-2 01.01, marc fleury at [EMAIL PROTECTED] wrote: The order of the Defenders is the ultimate one, work on the meta-system, and bring meta-order to the order less. It's self arranging once the system is there? One day there will be a *real* theoritical analysis of how Open Source organizes work. I believe there are stability points. But today we are winging it. It works, I'm just not sure why... passion, professionalism, youthfull enthusiasm, genius, creative anarchism, paternalism, idealism, fascism, OSS just seems to work. 'Edward de Bono' has several descriptionns of selforganising systems. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-549313 ] jdbc-rar/META-INF/ra.xml typo
Bugs item #549313, was opened at 2002-04-26 19:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549313group_id=22866 Category: JBossCX Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Ricardo Arguello (pajama) Assigned to: Nobody/Anonymous (nobody) Summary: jdbc-rar/META-INF/ra.xml typo Initial Comment: In JBoss HEAD: File jboss-all/connector/src/resources/jdbc-rar/META- INF/ra.xml Says this in line 50: connectionfactory-impl- classorg.jbossresource.adapter.jdbc.JDBCDataSource/co nnectionfactory-impl-class Should be: connectionfactory-impl- classorg.jboss.resource.adapter.jdbc.JDBCDataSource/c onnectionfactory-impl-class -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=549313group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 27-April-2002
Number of tests run: 585 Successful tests: 581 Errors:1 Failures: 3 [time of test: 27 April 2002 3:56 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-02a-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_green for details of this test. See http://lubega.com for general test information. 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 27-April-2002
Number of tests run: 585 Successful tests: 575 Errors:8 Failures: 2 [time of test: 27 April 2002 5:22 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131 for details of this test. See http://lubega.com for general test information. 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 27-April-2002
Number of tests run: 581 Successful tests: 570 Errors:9 Failures: 2 [time of test: 27 April 2002 6:51 GMT] [java.version: 1.3.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_02-b02] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131_02 for details of this test. See http://lubega.com for general test information. 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
