Re: Scott? RE: [JBoss-user] RE: [Beanshell-users] Re: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD
Seems like a rather independent feature that can't cause any harm. 3.2 is fine as is 3.0 as long as there truly are no backward compatibility issues with existing services. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED]; Adam Heath [EMAIL PROTECTED]; Jboss-Dev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, January 08, 2003 11:48 PM Subject: Scott? RE: [JBoss-user] RE: [Beanshell-users] Re: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD Scott, Do you accept the beanshell sub-deployer in pre-HEAD branches? 3.2? 3.0? Cheers, Sacha --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev]
ÔÚеÄÒ»ÄêÀףÄúÉíÌ彡¿µ£¬ÍòÊÂÈçÒ⣬²ÆÔ´¹ã½ø£¡£¡£¡ ÄúºÃ! ÎÒÊÇ˹ʢ¿Æ¼¼ÕÅ¿ªÇì ×£ÄúÍòÊÂÈçÒâ,¿ªÐÄ¿ìÀÖÐÒ¸£½¡¿µ,ÑòÄêµÃÖ¾£¡£¡£¡ TEL£º0755-26530145 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664453 ] 3.2beta3 breaks multi-partition config
Bugs item #664453, was opened at 2003-01-08 17:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=664453group_id=22866 Category: Clustering Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Matt Cleveland (groovesoftware) Assigned to: Nobody/Anonymous (nobody) Summary: 3.2beta3 breaks multi-partition config Initial Comment: The attached configuration is a slimmed down version of default with clustering added. It has been working just fine (with 3.0, 3.2beta1 and 3.2beta2) until 3.2beta3 and with 3.2beta3 it fails to start up and just hangs while initializing clustering. I am testing with 3.2beta3 with integrated tomcat 4.0.4, but I don't think the tomcat portion is involved. I am running on Solaris with JDK 1.3.1. I have also tested with the latest 3.2 from CVS and have the same problem there. The steps to reproduce are: 1. Clean installation of jboss 3.2beta3 with tomcat 4.0.4 2. unzip the attached zip file in the server directory 3. Start up the configuration prod-ejb1 4. Attempt to start up the configuration prod-ejb2 on the same machine. The startup will hang during cluster initialization. This bug is really hurting our progress and I am hoping it can be fixed in 3.2RC1. Thanks, Matt Cleveland -- Comment By: Sacha Labourey (slaboure) Date: 2003-01-09 10:04 Message: Logged In: YES user_id=95900 New JG release has been commited to HEAD, Branch_3_2 and Branch_3_0. -- Comment By: Sacha Labourey (slaboure) Date: 2003-01-08 22:06 Message: Logged In: YES user_id=95900 This comes from the current version of JG in JBoss. The problem has been fixed in JG. A new version of JG will be incoroporated before 3.0.5, tomorrow I hope. -- Comment By: Matt Cleveland (groovesoftware) Date: 2003-01-08 18:31 Message: Logged In: YES user_id=85088 I had to reduce the file size so it would attach, so please use the following steps to reproduce. 1. Make a copy of the default configuration named prod-ejb1 2. Make another copy of the default configuration named prod-ejb2 3. Copy the javagroups jar from the all configuration into the prod-ejb1 and prod-ejb2 configurations. 4. Unzip the attached jar in the server directory 5. Start up the configuration prod-ejb1 6. Attempt to start up the configuration prod-ejb2. The startup will hang during cluster initialization. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=664453group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Scott? RE: [JBoss-user] RE: [Beanshell-users] Re: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD
OK, I will backport it to 3.2 (not sure about doing it for 3.0) -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : jeudi, 9 janvier 2003 09:23 À : [EMAIL PROTECTED] Objet : Re: Scott? RE: [JBoss-user] RE: [Beanshell-users] Re: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD Seems like a rather independent feature that can't cause any harm. 3.2 is fine as is 3.0 as long as there truly are no backward compatibility issues with existing services. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED]; Adam Heath [EMAIL PROTECTED]; Jboss-Dev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, January 08, 2003 11:48 PM Subject: Scott? RE: [JBoss-user] RE: [Beanshell-users] Re: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD Scott, Do you accept the beanshell sub-deployer in pre-HEAD branches? 3.2? 3.0? Cheers, Sacha --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD
Just get it into the 3.0 build and provide a commented out setup of the deployer. That way people can use if they want, but its not enabled by default until it sees some action. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 1:04 AM Subject: RE: Scott? RE: [JBoss-user] RE: [Beanshell-users] Re: [JBoss-dev] ANNOUNCE: BeanShell JBoss sub-deployer in HEAD OK, I will backport it to 3.2 (not sure about doing it for 3.0) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Lost of session redeploying a servlet (Servlet.war)
Hi all: I have a problem with my servlet. The entire application ( e-commerce web page) is packed in myservlet.war. The servlet needs to know the session of the user in the web to handle security. When I build a new myservlet.war and JBoss make a new redeploy of the web, the old java objects are destroyed and the users of the web in that moment get a session expired because the servlet starts at point 0. How can I avoid the lost of the session and the process of redeploy be 'transparent' to the users , when I upload to the server a new version of the web? Thanks very much. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] New JBoss breaks CMP of serializable object fields (Upgrade from 3.0.2 to 3.0.4)
After upgrading from 3.0.2 to 3.0.4 it seems JBoss handles EJB properties of type Serializable in a different way. My whole solution is running the way it used to except for one thing: Those of my EJBs which have CMP fields which are of type serializable object fail. For instance, one of my beans has a field called validator which stores a serialized java object. After I started using JBoss 3.0.4 it was no longer possible to read these beans from the database. JBoss threw this exception: java.sql.SQLException: Got a [B[cl=0, value=[B@1ab7626] while looking for a dk.r ockit.puls.value.property.validator.Validator[cl=31889293] at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.coerceToJavaType(JDBCUtil.jav a:570) at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.getResult(JDBCUtil.java:437) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.load ArgumentResults(JDBCAbstractCMPFieldBridge.java:359) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.load InstanceResults(JDBCAbstractCMPFieldBridge.java:312) Extensive testing has shown that all EJBs which have a serializable object field with a non-null value cannot be read from or written to the database (a SAP DB). As another example, I have an EJB which has a field called menuBar which stores a serialized java object. When setting a non-null value for this field on my EJB I get the following exception: javax.ejb.EJBException: Internal error setting parameters for field menuBar; Cau sedByException is: Cannot put ASCII data into this long column at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setA rgumentParameters(JDBCAbstractCMPFieldBridge.java:297) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setI nstanceParameters(JDBCAbstractCMPFieldBridge.java:270) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.execute(JDBCSto reEntityCommand.java:85) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEntity(JDBCStore Manager.java:589) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity(CMPPersistenc eManager.java:458) Now, my database is exactly the same namely a SAP database, and I checked that the standardjbosscmp-jdbc configuration is also the same looking at the exception above it seems JBoss tries to store the object as a ascii string of some sort. Both my 3.0.2 and 3.0.4 has this setting mapping java-typejava.lang.Object/java-type jdbc-typeJAVA_OBJECT/jdbc-type sql-typeLONG BYTE/sql-type /mapping which is exactly the setting I want. I went as far as dropping the whole database and reconstructing it using the new 3.0.4 in hopes the error was caused by some inconsistency between the two versions no luck, the 3.0.4 is simply not able to handle my Serializable fields. If anyone has any idea what is different in JBoss 3.0.4 I shall be very pleased to hear from you. Finally I should mention that I based my 3.0.2 deployment on the all deployment configuration (with virtually no changes), and my 3.0.4 deployment is now based on the default deployment configuration (with virtually no changes). I did this to improve startup performance (it actually lowered the startup time by one third). Yours Randahl
[JBoss-dev] [ jboss-Bugs-665008 ] cache lists
Bugs item #665008, was opened at 2003-01-09 13:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665008group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Markus Menner (morphace) Assigned to: Nobody/Anonymous (nobody) Summary: cache lists Initial Comment: Hi, apparently cache-lists are not cleared correctly. In my case I used JB3.2b3 but it is the same with 3.0.4. My OS: WinXP, JDK 1.4.1_01 Yes, I have the CMP docs ... ;-) Here my standardjbosscmp-jdbc.xml settings: read-ahead strategyon-find/strategy page-size500/page-size eager-load-group*/eager-load-group /read-ahead list-cache-max1000/list-cache-max I use commit-option B, instance per transaction configuration for my CMP EJB's. When you execute a finder (in my case a dynamic EJB-QL finder) JBossCMP uses the read-ahead mechanism to optimize loading. So far, so good. For example three entites A, B and C. A's relationship to B is (A) 1-n (B) with a foreign-key. B's relationship to C is (B) n-1 (C) with a foreign-key. The B entities are read-ahead correctly. Now, the second case: Three entites D, E and B. D's relationship to E is (D) 1-n (E) with a foreign-key. B's relationship to E is (E) n-1 (B) with a foreign-key. When you execute a finder on D the cache-lists from the first finder execution are used! I noticed, that read-ahead is only working for 1-n relationships :-(, not for n-1 (is it a bug ? Anyway, I'll submit it). So normally you should get a query for each B, which is the case if you do not execute the first query, but if you do it, the B's are read-ahead corresponding to the cache-lists of the first query!? I hope that I explained everything enough. TX Markus -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665008group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665013 ] Read ahead
Bugs item #665013, was opened at 2003-01-09 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665013group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Markus Menner (morphace) Assigned to: Nobody/Anonymous (nobody) Summary: Read ahead Initial Comment: Hi, apparently read-ahead is only working for 1-n relationships :-(, not for n-1. In my case I used JB3.2b3 but it is the same with 3.0.4. My OS: WinXP, JDK 1.4.1_01 Yes, I have the CMP docs ... ;-) Here my standardjbosscmp-jdbc.xml settings: read-ahead strategyon-find/strategy page-size500/page-size eager-load-group*/eager-load-group /read-ahead list-cache-max1000/list-cache-max I use commit-option B, instance per transaction configuration for my CMP EJB's. I looked at the code, and (I hope that I am right) it's clear that it does not work, because the read-ahead mechanism relies on the collection of primary keys (not foreign keys). I feel, that it could be (easily ;-)) done by collecting the foreign keys too and due to the fact that the current behavior has grave performance loss I submit it as bug. Is it okay ? TX Markus -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665013group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665013 ] Read ahead
Bugs item #665013, was opened at 2003-01-09 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665013group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 8 Submitted By: Markus Menner (morphace) Assigned to: Nobody/Anonymous (nobody) Summary: Read ahead Initial Comment: Hi, apparently read-ahead is only working for 1-n relationships :-(, not for n-1. In my case I used JB3.2b3 but it is the same with 3.0.4. My OS: WinXP, JDK 1.4.1_01 Yes, I have the CMP docs ... ;-) Here my standardjbosscmp-jdbc.xml settings: read-ahead strategyon-find/strategy page-size500/page-size eager-load-group*/eager-load-group /read-ahead list-cache-max1000/list-cache-max I use commit-option B, instance per transaction configuration for my CMP EJB's. I looked at the code, and (I hope that I am right) it's clear that it does not work, because the read-ahead mechanism relies on the collection of primary keys (not foreign keys). I feel, that it could be (easily ;-)) done by collecting the foreign keys too and due to the fact that the current behavior has grave performance loss I submit it as bug. Is it okay ? TX Markus -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665013group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] LoadBalancePolicy interface
hello
I would like to ask: What targets list contains ? Which class objects ?
public class RoundRobin implements LoadBalancePolicy
{
...
public Object chooseTarget(java.util.List targets)
{
cursorRemote = ( (cursorRemote + 1) % targets.size() );
return targets.get(cursorRemote);
}
}
thanx
Maris Orbidans
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] LoadBalancePolicy interface
From the point of view of the LBP, it is not important to know what's in it:
you have to elect one object, that's all.
(the list contains RMI proxies for the HA-JRMP RMI Server)
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Maris Orbidans
Envoyé : jeudi, 9 janvier 2003 15:18
À : [EMAIL PROTECTED]
Objet : [JBoss-dev] LoadBalancePolicy interface
hello
I would like to ask: What targets list contains ? Which class
objects ?
public class RoundRobin implements LoadBalancePolicy
{
...
public Object chooseTarget(java.util.List targets)
{
cursorRemote = ( (cursorRemote + 1) % targets.size() );
return targets.get(cursorRemote);
}
}
thanx
Maris Orbidans
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665037 ] HomeHandle causing NoInitialContextException in JBOSS3.0.4
Bugs item #665037, was opened at 2003-01-09 14:32
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665037group_id=22866
Category: JBossServer
Group: v4.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Shone Sadler (ssadler)
Assigned to: Nobody/Anonymous (nobody)
Summary: HomeHandle causing NoInitialContextException in JBOSS3.0.4
Initial Comment:
When running our remote clients we get a
NoInitialContextException. The exception is caused by
a call to HomeHandle.getEJBHome(). After Looking
through the source code for JBOSS, it seems that
JBOSS 3.0.4's
com.jboss.proxy.ejb.handle.HomeHandleImpl does not
serialize the JNDI context information like is should (and
used to in JBOSS2.4. Instead it always creates a new
InitialContext in the getEJBHome method. The following
example illustrates the problem.
import
com.qlinktech.pof3.omapi.POFObjectManagerRemoteHo
me;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.ejb.HomeHandle;
import java.util.Properties;
public class Example {
public static void main(String[] args) throws Exception
{
Properties _prop = new Properties();
_prop.setProperty
(java.naming.factory.initial,org.jnp.interfaces.NamingC
ontextFactory);
_prop.setProperty
(java.naming.factory.url.pkgs,org.jboss.naming:org.jnp.
interfaces);
_prop.setProperty
(java.naming.provider.url,localhost);
_prop.setProperty
(java.naming.provider.port,1099);
InitialContext _ic = new InitialContext(_prop);
POFObjectManagerRemoteHome _om_home =
(POFObjectManagerRemoteHome)
PortableRemoteObject.narrow(_ic.lookup
(qlink/POFObjectManager),POFObjectManagerRemote
Home.class);
HomeHandle _hhandle = _om_home.getHomeHandle
();
//Here is where the NoInitialContextException is
thrown
_om_home = (POFObjectManagerRemoteHome)
javax.rmi.PortableRemoteObject.narrow
(_hhandle.getEJBHome
(),POFObjectManagerRemoteHome.class);
}
}
Thanks,
Shone Sadler
Senior Software Developer
Q-Link Technologies
OS: Win2000
JDK:1.3.1_06
Server Trace:
C:\developmentjava Example
Exception in thread main java.rmi.ServerException:
Could not get EJBHome; nes
ed exception is:
javax.naming.NoInitialContextException: Need to
specify class name in e
vironment or system property, or as an applet
parameter, or in an application r
source file: java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify
class name in environme
t or system property, or as an applet parameter, or in an
application resource
ile: java.naming.factory.initial
at
javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:
38)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:24
)
at
javax.naming.InitialContext.getURLOrDefaultInitCtx
(InitialContext.ja
a:278)
at javax.naming.InitialContext.lookup
(InitialContext.java:345)
at
org.jboss.proxy.ejb.handle.HomeHandleImpl.getEJBHom
e(HomeHandleImpl.
ava:72)
at Example.main(Example.java:29)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665037group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665037 ] HomeHandle causing NoInitialContextException in JBOSS3.0.4
Bugs item #665037, was opened at 2003-01-09 14:32
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665037group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Shone Sadler (ssadler)
Assigned to: Nobody/Anonymous (nobody)
Summary: HomeHandle causing NoInitialContextException in JBOSS3.0.4
Initial Comment:
When running our remote clients we get a
NoInitialContextException. The exception is caused by
a call to HomeHandle.getEJBHome(). After Looking
through the source code for JBOSS, it seems that
JBOSS 3.0.4's
com.jboss.proxy.ejb.handle.HomeHandleImpl does not
serialize the JNDI context information like is should (and
used to in JBOSS2.4. Instead it always creates a new
InitialContext in the getEJBHome method. The following
example illustrates the problem.
import
com.qlinktech.pof3.omapi.POFObjectManagerRemoteHo
me;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.ejb.HomeHandle;
import java.util.Properties;
public class Example {
public static void main(String[] args) throws Exception
{
Properties _prop = new Properties();
_prop.setProperty
(java.naming.factory.initial,org.jnp.interfaces.NamingC
ontextFactory);
_prop.setProperty
(java.naming.factory.url.pkgs,org.jboss.naming:org.jnp.
interfaces);
_prop.setProperty
(java.naming.provider.url,localhost);
_prop.setProperty
(java.naming.provider.port,1099);
InitialContext _ic = new InitialContext(_prop);
POFObjectManagerRemoteHome _om_home =
(POFObjectManagerRemoteHome)
PortableRemoteObject.narrow(_ic.lookup
(qlink/POFObjectManager),POFObjectManagerRemote
Home.class);
HomeHandle _hhandle = _om_home.getHomeHandle
();
//Here is where the NoInitialContextException is
thrown
_om_home = (POFObjectManagerRemoteHome)
javax.rmi.PortableRemoteObject.narrow
(_hhandle.getEJBHome
(),POFObjectManagerRemoteHome.class);
}
}
Thanks,
Shone Sadler
Senior Software Developer
Q-Link Technologies
OS: Win2000
JDK:1.3.1_06
Server Trace:
C:\developmentjava Example
Exception in thread main java.rmi.ServerException:
Could not get EJBHome; nes
ed exception is:
javax.naming.NoInitialContextException: Need to
specify class name in e
vironment or system property, or as an applet
parameter, or in an application r
source file: java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify
class name in environme
t or system property, or as an applet parameter, or in an
application resource
ile: java.naming.factory.initial
at
javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:
38)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:24
)
at
javax.naming.InitialContext.getURLOrDefaultInitCtx
(InitialContext.ja
a:278)
at javax.naming.InitialContext.lookup
(InitialContext.java:345)
at
org.jboss.proxy.ejb.handle.HomeHandleImpl.getEJBHom
e(HomeHandleImpl.
ava:72)
at Example.main(Example.java:29)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665037group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665067 ] Managed Connection equals Null! Problems in JBOSS 3.0.3
Bugs item #665067, was opened at 2003-01-09 16:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665067group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Michael Ukpong (michaelukpong) Assigned to: Nobody/Anonymous (nobody) Summary: Managed Connection equals Null! Problems in JBOSS 3.0.3 Initial Comment: The .remove() method of some Entity beans I wrote and deployed in JBoss 3.0.0 is now throwing a Managed Connection = null exception in Jboss 3.0.3. I earlier noticed that these entities gave a you are not getting the semantics you expect warning (both in Jboss 3.0.0 and 3.0.3) but I ignored this warning in Jboss 3.0.0. Could this be the cause of the exception now thrown in Jboss 3.0.3? The funny thing is that if you keep looping on the remove (), where the number of iterations is the record length of the underlying table + 1, it eventually works! So its like the managed connection is restored after a certain number of failed attempts. What could this mean? Note that this remove() method is NOT called directly from a servlet, but through a stateless session bean. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665067group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] LoadBalancePolicy interface
thanx Sacha
I asked that because I have an idea to improve load balancing of JBoss, maybe even to
use some kind of neural network.
( http://www.jboss.org/forums/thread.jsp?forum=155thread=26907 )
Do you think it's possible using your existing codebase ?
Neural network (or any advanced LB algorithm) would need to gather a lots of
information (for example, execution time of RPCs
for each server), to optimize LB.
LoadBalancePolicy interface seems too simple to achieve all that. But I havent spent
much time digging JBoss code yet.
Maris
PS I am searching a good topic for my thesis, that's why I am interested.
-Original Message-
From: Sacha Labourey [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 09, 2003 4:29 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] LoadBalancePolicy interface
From the point of view of the LBP, it is not important to
know what's in it:
you have to elect one object, that's all.
(the list contains RMI proxies for the HA-JRMP RMI Server)
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Maris Orbidans
Envoyé : jeudi, 9 janvier 2003 15:18
À : [EMAIL PROTECTED]
Objet : [JBoss-dev] LoadBalancePolicy interface
hello
I would like to ask: What targets list contains ? Which class
objects ?
public class RoundRobin implements LoadBalancePolicy
{
...
public Object chooseTarget(java.util.List targets)
{
cursorRemote = ( (cursorRemote + 1) % targets.size() );
return targets.get(cursorRemote);
}
}
thanx
Maris Orbidans
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] LoadBalancePolicy interface
Well, for this we would need to wrap the proxy inside another object, which
was already on the todo list. Then, you can attach whatever you want to this
proxy. Nevertheless, the list of proxies (and thus the data attached to
them) is only updated if the network topology changes. Consequently, if you
want to provide some information to the client side, you may want to attach
information to the invocation object instead (which is already possible) and
provide information to your load balancing policy. Anyway, I would use the
3.2 or HEAD codebase to work on that and not the 3.0 as the LB code has been
changed in 3.2/head.
Cheers,
Sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Maris Orbidans
Envoyé : jeudi, 9 janvier 2003 16:18
À : [EMAIL PROTECTED]
Objet : RE: [JBoss-dev] LoadBalancePolicy interface
thanx Sacha
I asked that because I have an idea to improve load balancing of
JBoss, maybe even to use some kind of neural network.
( http://www.jboss.org/forums/thread.jsp?forum=155thread=26907 )
Do you think it's possible using your existing codebase ?
Neural network (or any advanced LB algorithm) would need to
gather a lots of information (for example, execution time of RPCs
for each server), to optimize LB.
LoadBalancePolicy interface seems too simple to achieve all that.
But I havent spent much time digging JBoss code yet.
Maris
PS I am searching a good topic for my thesis, that's why I am interested.
-Original Message-
From: Sacha Labourey [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 09, 2003 4:29 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] LoadBalancePolicy interface
From the point of view of the LBP, it is not important to
know what's in it:
you have to elect one object, that's all.
(the list contains RMI proxies for the HA-JRMP RMI Server)
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Maris Orbidans
Envoyé : jeudi, 9 janvier 2003 15:18
À : [EMAIL PROTECTED]
Objet : [JBoss-dev] LoadBalancePolicy interface
hello
I would like to ask: What targets list contains ? Which class
objects ?
public class RoundRobin implements LoadBalancePolicy
{
...
public Object chooseTarget(java.util.List targets)
{
cursorRemote = ( (cursorRemote + 1) % targets.size() );
return targets.get(cursorRemote);
}
}
thanx
Maris Orbidans
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] LoadBalancePolicy interface
Or it may contain something else. For HA-RMI/HTTP the targets are the URLs of the invoker servlets in the clusters. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 6:28 AM Subject: RE: [JBoss-dev] LoadBalancePolicy interface From the point of view of the LBP, it is not important to know what's in it: you have to elect one object, that's all. (the list contains RMI proxies for the HA-JRMP RMI Server) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 11:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
[JBoss-dev] [ jboss-Bugs-665192 ] links broken on the projects page
Bugs item #665192, was opened at 2003-01-09 13:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665192group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: links broken on the projects page Initial Comment: I couldn't find a website category for this, so I just set the category to none. The following page has several broken links. http://jboss.org/developers/projects/jboss/projects.php - Matt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665192group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] PHP
Hi all, I just noticed that many of the pages on the website end in .php. Has it always been this way, or is it new? I'd be very interested in hearing the rationale for using PHP over a servlet-based or other solution. I'm not all-to familiar with PHP, but I'm seeing it a lot lately... - Matt --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
new website. Its PHP and PostNuke. Its OK. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. Julien Viet is looking into porting it to the Java world. We're gonna call it JNuke. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 1:38 PM To: JBoss Developers Group (E-mail) Subject: [JBoss-dev] PHP Hi all, I just noticed that many of the pages on the website end in .php. Has it always been this way, or is it new? I'd be very interested in hearing the rationale for using PHP over a servlet-based or other solution. I'm not all-to familiar with PHP, but I'm seeing it a lot lately... - Matt --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
Bill, Don't worry, I'm not going to blast you for not eating your own dog food. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) We're gonna call it JNuke sounds interesting... - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 1:55 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP new website. Its PHP and PostNuke. Its OK. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. Julien Viet is looking into porting it to the Java world. We're gonna call it JNuke. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 1:38 PM To: JBoss Developers Group (E-mail) Subject: [JBoss-dev] PHP Hi all, I just noticed that many of the pages on the website end in .php. Has it always been this way, or is it new? I'd be very interested in hearing the rationale for using PHP over a servlet-based or other solution. I'm not all-to familiar with PHP, but I'm seeing it a lot lately... - Matt --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
Funny, I was just doing research for a CMS that offers webdav access,
versioning, workflow, etc. as you find in most real CMSs (not those
incessent fake ones)..
I was about this close {index fingers almost touching} to going with
Post-Nuke.. My reasons not to? Well, most of the people that would help
me were Java guys.. PHP is easy, but why change? Also, the fact that
there is some warring and branching going on, so extending it would be a
political nightmare to weed through (nice - I like this extension -
what?? It only supports the Bob branch!!). Finally, the code for PHP is
always a pain, so integrating new functionality is sometimes more
painful than just writing it yourself.. That shouldn't be the case, but
that's PHP - hack first, never clean it later..
I for one would love to see a JNuke.. Viet, do you have a sourceforge
project started for this or anything, so we can help out? I'm really in
need of a portal hosting (ala sourceforge) solution, but a single
content portal ala Post-Nuke would be a great start..
BTW, I finally settled on Jakarta Slide (WebDAV, versioning) and a
custom workflow component (OSWorkflow has too many problems with their
volunteers and too much buy in for their framework of doom). I just need
a good client now, which I'll probably use an OSS one and rewrite over
time as the user's needs change.
James
-Original Message-
From: Matt Munz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 09, 2003 1:22 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] PHP
Bill,
Don't worry, I'm not going to blast you for not eating your
own dog food.
JSP/Servlets/J2EE is better, but PostNuke is a good Content
Management
System.
This statement, in and of itself, is a rationale for using
J2EE instead of PHP ;) Could you divulge the precise
reason(s) for choosing Post-Nuke? (I can think of many
factors that often outweigh technical superiority -- time,
money, expedience, IP issues... was it one of these?)
We're gonna call it JNuke
sounds interesting...
- Matt
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 09, 2003 1:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] PHP
new website. Its PHP and PostNuke. Its OK.
JSP/Servlets/J2EE is better, but PostNuke is a good Content
Management System. Julien Viet is looking into porting it to
the Java world. We're gonna call it JNuke.
Bill Burke
Chief Architect
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Matt Munz
Sent: Thursday, January 09, 2003 1:38 PM
To: JBoss Developers Group (E-mail)
Subject: [JBoss-dev] PHP
Hi all,
I just noticed that many of the pages on the website end
in .php.
Has it always been this way, or is it new? I'd be very
interested in
hearing the rationale for using PHP over a servlet-based or other
solution. I'm not all-to familiar with PHP, but I'm seeing
it a lot
lately...
- Matt
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something
2 See! http://www.vasoftware.com
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2
See! http://www.vasoftware.com
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] PHP problems
OK so we are really in a bind here. The script kiddy code may be functional, this lack of caching is really killing us. The site is pegged at 100 with dips at 50% on occasion but all in all the profile looks pretty bad. The Java code was 3 times faster. I feel good on one hand because this is yet another point in the cache is king category but it is also horrible scalability. It also makes the website next to un-usable since the response time is so bad. Next time I hear some ignorant bozo tell me apache is fast and c is fast and java is slow I take my baseball bat and smash his head in. I am tired of the rampant ignorance even among the geeks. It is just amusing at this point. We need to port the functionality we use in the website one to one with EJB's backing it up and offering some caching so we can multiply the speed by 10 and go back to our usual 10% CPU utilization. JNUKE will be a killer project. marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
interesting.
We went with PN for the functionality. It was there for the taking, it
worked.
but man does it NOT scale. I mean we have about 100 people on the site
(I love that counter thingy).
JNUKE is needed badly. As I said I just hired julien to do it with
JBoss it is a perfect time
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of James Higginbotham
Sent: Thursday, January 09, 2003 2:46 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] PHP
Funny, I was just doing research for a CMS that offers webdav
access, versioning, workflow, etc. as you find in most real
CMSs (not those incessent fake ones)..
I was about this close {index fingers almost touching} to
going with Post-Nuke.. My reasons not to? Well, most of the
people that would help me were Java guys.. PHP is easy, but
why change? Also, the fact that there is some warring and
branching going on, so extending it would be a political
nightmare to weed through (nice - I like this extension -
what?? It only supports the Bob branch!!). Finally, the code
for PHP is always a pain, so integrating new functionality is
sometimes more painful than just writing it yourself.. That
shouldn't be the case, but that's PHP - hack first, never
clean it later..
I for one would love to see a JNuke.. Viet, do you have a
sourceforge project started for this or anything, so we can
help out? I'm really in need of a portal hosting (ala
sourceforge) solution, but a single content portal ala
Post-Nuke would be a great start..
BTW, I finally settled on Jakarta Slide (WebDAV, versioning)
and a custom workflow component (OSWorkflow has too many
problems with their volunteers and too much buy in for their
framework of doom). I just need a good client now, which I'll
probably use an OSS one and rewrite over time as the user's
needs change.
James
-Original Message-
From: Matt Munz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 09, 2003 1:22 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] PHP
Bill,
Don't worry, I'm not going to blast you for not eating your
own dog food.
JSP/Servlets/J2EE is better, but PostNuke is a good Content
Management
System.
This statement, in and of itself, is a rationale for using
J2EE instead of PHP ;) Could you divulge the precise
reason(s) for choosing Post-Nuke? (I can think of many
factors that often outweigh technical superiority -- time,
money, expedience, IP issues... was it one of these?)
We're gonna call it JNuke
sounds interesting...
- Matt
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 09, 2003 1:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] PHP
new website. Its PHP and PostNuke. Its OK.
JSP/Servlets/J2EE is better, but PostNuke is a good Content
Management System. Julien Viet is looking into porting it to
the Java world. We're gonna call it JNuke.
Bill Burke
Chief Architect
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Matt Munz
Sent: Thursday, January 09, 2003 1:38 PM
To: JBoss Developers Group (E-mail)
Subject: [JBoss-dev] PHP
Hi all,
I just noticed that many of the pages on the website end
in .php.
Has it always been this way, or is it new? I'd be very
interested in
hearing the rationale for using PHP over a servlet-based or other
solution. I'm not all-to familiar with PHP, but I'm seeing
it a lot
lately...
- Matt
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something
2 See! http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =omething 2
See! http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld
http://www.vasoftware.com
Re[2]: [JBoss-dev] PHP
What's good in PN is that the underlying model is proven to work. Also reusing all HTML, CSS and icons is very good. I am a java coder not a web designer. While developping forums app, the lack of HTML development slowed me a lot. In the port reusing their will help a lot : HTML and all that stuff. Believe me that's 50% of development time, if not greater. julien MM Bill, MM Don't worry, I'm not going to blast you for not eating your own dog food. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. MM This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh MM technical superiority -- time, money, expedience, IP issues... was it one of these?) We're gonna call it JNuke MM sounds interesting... MM - Matt MM -Original Message- MM From: Bill Burke [mailto:[EMAIL PROTECTED]] MM Sent: Thursday, January 09, 2003 1:55 PM MM To: [EMAIL PROTECTED] MM Subject: RE: [JBoss-dev] PHP MM new website. Its PHP and PostNuke. Its OK. JSP/Servlets/J2EE is better, MM but PostNuke is a good Content Management System. Julien Viet is looking MM into porting it to the Java world. We're gonna call it JNuke. MM MM Bill Burke MM Chief Architect MM JBoss Group, LLC MM -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 1:38 PM To: JBoss Developers Group (E-mail) Subject: [JBoss-dev] PHP Hi all, I just noticed that many of the pages on the website end in .php. Has it always been this way, or is it new? I'd be very interested in hearing the rationale for using PHP over a servlet-based or other solution. I'm not all-to familiar with PHP, but I'm seeing it a lot lately... - Matt --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development MM --- MM This SF.NET email is sponsored by: MM SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! MM http://www.vasoftware.com MM ___ MM Jboss-development mailing list MM [EMAIL PROTECTED] MM https://lists.sourceforge.net/lists/listinfo/jboss-development MM --- MM This SF.NET email is sponsored by: MM SourceForge Enterprise Edition + IBM + LinuxWorld Something 2 See! MM http://www.vasoftware.com MM ___ MM Jboss-development mailing list MM [EMAIL PROTECTED] MM https://lists.sourceforge.net/lists/listinfo/jboss-development -- Best regards, julienmailto:[EMAIL PROTECTED] ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP problems
Marc, Don't forget that hardware is cheap compared to man-hours. If you're writing tissue-paper code (write once, never modify, throw away when broken), script kiddie languages are great. If not, be prepared to eat it in the long run on man hours / maintennance. I think that the use of the tissue-paper methodology flies in the face of OSS. Why bother to open-source your IP if nobody will ever read it and you're just going to throw it away anyway? I'm glad to hear that this is a stopgap solution. BTW, thanks for providing a real-world case to justify my PHP allergy :) - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:56 PM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] PHP problems OK so we are really in a bind here. The script kiddy code may be functional, this lack of caching is really killing us. The site is pegged at 100 with dips at 50% on occasion but all in all the profile looks pretty bad. The Java code was 3 times faster. I feel good on one hand because this is yet another point in the cache is king category but it is also horrible scalability. It also makes the website next to un-usable since the response time is so bad. Next time I hear some ignorant bozo tell me apache is fast and c is fast and java is slow I take my baseball bat and smash his head in. I am tired of the rampant ignorance even among the geeks. It is just amusing at this point. We need to port the functionality we use in the website one to one with EJB's backing it up and offering some caching so we can multiply the speed by 10 and go back to our usual 10% CPU utilization. JNUKE will be a killer project. marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[2]: [JBoss-dev] PHP
I agree Julien. HTML/CSS sucks. Takes about 80% of my time when I do it. In fact, the port to PostNuke would have taken me 1 or 2 days less. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Thursday, January 09, 2003 3:31 PM To: [EMAIL PROTECTED]; Matt Munz Cc: [EMAIL PROTECTED] Subject: Re[2]: [JBoss-dev] PHP What's good in PN is that the underlying model is proven to work. Also reusing all HTML, CSS and icons is very good. I am a java coder not a web designer. While developping forums app, the lack of HTML development slowed me a lot. In the port reusing their will help a lot : HTML and all that stuff. Believe me that's 50% of development time, if not greater. julien MM Bill, MM Don't worry, I'm not going to blast you for not eating your own dog food. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. MM This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh MM technical superiority -- time, money, expedience, IP issues... was it one of these?) We're gonna call it JNuke MM sounds interesting... MM - Matt MM -Original Message- MM From: Bill Burke [mailto:[EMAIL PROTECTED]] MM Sent: Thursday, January 09, 2003 1:55 PM MM To: [EMAIL PROTECTED] MM Subject: RE: [JBoss-dev] PHP MM new website. Its PHP and PostNuke. Its OK. JSP/Servlets/J2EE is better, MM but PostNuke is a good Content Management System. Julien Viet is looking MM into porting it to the Java world. We're gonna call it JNuke. MM MM Bill Burke MM Chief Architect MM JBoss Group, LLC MM -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 1:38 PM To: JBoss Developers Group (E-mail) Subject: [JBoss-dev] PHP Hi all, I just noticed that many of the pages on the website end in .php. Has it always been this way, or is it new? I'd be very interested in hearing the rationale for using PHP over a servlet-based or other solution. I'm not all-to familiar with PHP, but I'm seeing it a lot lately... - Matt --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development MM --- MM This SF.NET email is sponsored by: MM SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! MM http://www.vasoftware.com MM ___ MM Jboss-development mailing list MM [EMAIL PROTECTED] MM https://lists.sourceforge.net/lists/listinfo/jboss-development MM --- MM This SF.NET email is sponsored by: MM SourceForge Enterprise Edition + IBM + LinuxWorld Something 2 See! MM http://www.vasoftware.com MM ___ MM Jboss-development mailing list MM [EMAIL PROTECTED] MM https://lists.sourceforge.net/lists/listinfo/jboss-development -- Best regards, julienmailto:[EMAIL PROTECTED] ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en frangais ! Yahoo! Mail : http://fr.mail.yahoo.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[2]: [JBoss-dev] PHP
I agree Julien. HTML/CSS sucks. Takes about 80% of my time when I do it. In fact, the port to PostNuke would have taken me 1 or 2 days less. given that it took you 4 days that would be a feat indeed :) marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP problems
Don't forget that hardware is cheap compared to man-hours. If you're writing tissue-paper code (write once, never modify, throw away when broken), script kiddie languages are great. right interestingly enough we might have to upgrade the machine just to get decent response times on the forums (where most of the database access is done). The notion of caching is lost on script kiddies. Never again will I tolerate a discussion on C vs Java or Apache vs JBoss or EJB vs direct JDBC. I am laughing my head off today, this computing thing is easy marcf - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:56 PM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] PHP problems OK so we are really in a bind here. The script kiddy code may be functional, this lack of caching is really killing us. The site is pegged at 100 with dips at 50% on occasion but all in all the profile looks pretty bad. The Java code was 3 times faster. I feel good on one hand because this is yet another point in the cache is king category but it is also horrible scalability. It also makes the website next to un-usable since the response time is so bad. Next time I hear some ignorant bozo tell me apache is fast and c is fast and java is slow I take my baseball bat and smash his head in. I am tired of the rampant ignorance even among the geeks. It is just amusing at this point. We need to port the functionality we use in the website one to one with EJB's backing it up and offering some caching so we can multiply the speed by 10 and go back to our usual 10% CPU utilization. JNUKE will be a killer project. marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 9-January-2003
JBoss daily test results SUMMARY Number of tests run: 1010 Successful tests: 1004 Errors:5 Failures: 1 [time of test: 2003-01-09.12-02 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.3] See http://users.jboss.org/~starksm/Branch_3_0/2003-01-09.12-02 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.security.auth.login.LoginException Message: Missing users.properties file. - Suite: SimpleUnitTestCase Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.AuthenticationException Message: Failed to login using protocol=testLoginInitialContext - Suite: HttpsUnitTestCase Test:testHttpsURL(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.io.IOException Message: Failed to get SSLContext for TLS algorithm - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. DNE == Does not exist DNYE == Does NOT YET exist JNUKE JNUKE JNUKE (Nukes on JBoss/ JNUKE is the official name). Enterprise PHP finally!!! It is also such a justification of all the work we do... I never realized it before. I went from java might be fast enough to serve websites (2 year ago) to java is good enough to serve website (1 year ago) to java is the only real way to go (right today). The problem is that PHP approach doesn't lend itself to component reuse. EJB's are the way to go. IT is so blindingly trivial, the caches the caches! Julien is already trying to generate 1EJB per table and see if we can move ahead on the port. Since the look is already done that will be easier. Man we are going to have a blast doing that port. marcf Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] PHP problems
Matt Munz wrote: Marc, If you're writing tissue-paper code (write once, never modify, throw away when broken), script kiddie languages are great. If not, be prepared to eat it in the long run on man hours / maintennance. And remember that eating used tissue-paper is never a good thing. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
FW: PostNuke / JNuke (Fw: [JBoss-dev] PHP)
Screw em. We have the development community and development process. They don't. -Original Message- From: Andreas Kuckartz [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 3:54 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: PostNuke / JNuke (Fw: [JBoss-dev] PHP) A mail from the jboss list about the CMS used by jboss.org: PostNuke and a new one: JNuke. There exist at least two projects named jnuke: http://jnuke.sourceforge.net/ http://j2ee-nuke.sourceforge.net/ The first one seems to be dead while the second one only a few weeks old. Andreas - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 7:54 PM Subject: RE: [JBoss-dev] PHP new website. Its PHP and PostNuke. Its OK. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. Julien Viet is looking into porting it to the Java world. We're gonna call it JNuke. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 1:38 PM To: JBoss Developers Group (E-mail) Subject: [JBoss-dev] PHP Hi all, I just noticed that many of the pages on the website end in .php. Has it always been this way, or is it new? I'd be very interested in hearing the rationale for using PHP over a servlet-based or other solution. I'm not all-to familiar with PHP, but I'm seeing it a lot lately... - Matt --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[2]: [JBoss-dev] PHP
What's good in PN is that the underlying model is proven to work. Also reusing all HTML, CSS and icons is very good. yes all the functionality is KICK ASS. Just take it and solidify it with a refactor port to JBoss as you are moving forward with it. I am a java coder not a web designer. While developping forums app, the lack of HTML development slowed me a lot. In the port reusing their will help a lot : HTML and all that stuff. Believe me that's 50% of development time, if not greater. The web interface is all the time in the world. I suspect this port won't take much time at all. Nukes on JBoss is going to be SUCH A GREAT PROJECT. Finally ENTERPRISE CMS for the MASSES. ahahahahahahahah evil-laugh/ marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: PostNuke / JNuke (Fw: [JBoss-dev] PHP)
it is not a separate project on sourceforge anyway this is fully a JBoss project nukes on JBoss aka JNUKE (the one and only :) marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Thursday, January 09, 2003 3:50 PM To: Jboss-Dev Cc: [EMAIL PROTECTED] Subject: FW: PostNuke / JNuke (Fw: [JBoss-dev] PHP) Screw em. We have the development community and development process. They don't. -Original Message- From: Andreas Kuckartz [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 3:54 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: PostNuke / JNuke (Fw: [JBoss-dev] PHP) A mail from the jboss list about the CMS used by jboss.org: PostNuke and a new one: JNuke. There exist at least two projects named jnuke: http://jnuke.sourceforge.net/ http://j2ee-nuke.sourceforge.net/ The first one seems to be dead while the second one only a few weeks old. Andreas - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 7:54 PM Subject: RE: [JBoss-dev] PHP new website. Its PHP and PostNuke. Its OK. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. Julien Viet is looking into porting it to the Java world. We're gonna call it JNuke. Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 1:38 PM To: JBoss Developers Group (E-mail) Subject: [JBoss-dev] PHP Hi all, I just noticed that many of the pages on the website end in .php. Has it always been this way, or is it new? I'd be very interested in hearing the rationale for using PHP over a servlet-based or other solution. I'm not all-to familiar with PHP, but I'm seeing it a lot lately... - Matt --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP problems
what's a pronoun? :) - Matt -Original Message- From: danch [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 3:49 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] PHP problems Matt Munz wrote: Marc, If you're writing tissue-paper code (write once, never modify, throw away when broken), script kiddie languages are great. If not, be prepared to eat it in the long run on man hours / maintennance. And remember that eating used tissue-paper is never a good thing. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] One thing I like about the Apache thing
admit the nightmare of scalability with PN there is one thing that caught my eye. I really had forgotten how nice it is to edit a webpage and see it picked up live by the webserver. It sounds like nothing but we really lost something with this stupid EAR/WAR packaging nightmare. We already support exploded deployment. Is there a way we can do partial redeployment of at least the static pages in JBoss? So we can edit the page quick without having to redeploy the full site? If I am lost and it is already done let me know and I will be quiet. marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP problems
Matt Munz wrote: Marc, If you're writing tissue-paper code (write once, never modify, throw away when broken), script kiddie languages are great. If not, be prepared to eat it in the long run on man hours / maintennance. And remember that eating used tissue-paper is never a good thing. LOL yeah. That being said I think the approach is not bad, you know me. Bad code that works that is great! I wish we did more of that in java in general too much MVC too much model 2 too much separation of concerns too much wanking if you ask me. Same for JBoss sometimes. Keep it simple and get it working. Good for the kiddies. There is an equilibrium between the mess that results and the rigid approach most java purist take. If we can strike that balance with nukes on jboss marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 11:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
Re: [JBoss-dev] One thing I like about the Apache thing
It is already there. Many times I have gone in and edited the jboss.org site content in the unpacked war to pick it changes. Its not even a redeployment. The web container watches the timestamps on the web content. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: marc fleury [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 12:58 PM Subject: [JBoss-dev] One thing I like about the Apache thing admit the nightmare of scalability with PN there is one thing that caught my eye. I really had forgotten how nice it is to edit a webpage and see it picked up live by the webserver. It sounds like nothing but we really lost something with this stupid EAR/WAR packaging nightmare. We already support exploded deployment. Is there a way we can do partial redeployment of at least the static pages in JBoss? So we can edit the page quick without having to redeploy the full site? If I am lost and it is already done let me know and I will be quiet. marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Re[2]: [JBoss-dev] PHP
just found it: XLVIII. Java There are two possible ways to bridge PHP and Java: you can either integrate PHP into a Java Servlet environment, which is the more stable and efficient solution, or integrate Java support into PHP. The former is provided by a SAPI module that interfaces with the Servlet server, the latter by the Java extension. at: http://php.benscom.com/manual/kr/ref.java.php bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +--+ | Zend Engine | +--+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +--+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt.| | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +--+ | Authors: Andi Gutmans [EMAIL PROTECTED]| | Zeev Suraski [EMAIL PROTECTED]| +--+ */ HB anybody thought about integrating php (and this way the cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite
RE: [JBoss-dev] One thing I like about the Apache thing
I was not aware of this. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: Thursday, January 09, 2003 6:00 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] One thing I like about the Apache thing It is already there. Many times I have gone in and edited the jboss.org site content in the unpacked war to pick it changes. Its not even a redeployment. The web container watches the timestamps on the web content. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: marc fleury [EMAIL PROTECTED] To: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 12:58 PM Subject: [JBoss-dev] One thing I like about the Apache thing admit the nightmare of scalability with PN there is one thing that caught my eye. I really had forgotten how nice it is to edit a webpage and see it picked up live by the webserver. It sounds like nothing but we really lost something with this stupid EAR/WAR packaging nightmare. We already support exploded deployment. Is there a way we can do partial redeployment of at least the static pages in JBoss? So we can edit the page quick without having to redeploy the full site? If I am lost and it is already done let me know and I will be quiet. marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
Yeah that was my first impulse, to have a PHP interpreter in JBoss so that we could leverage all the PHP thingies out there. clearly the problem with PHP is that the guys who do the front end modules and app DONT KNOW THE FIRST THING ABOUT COMPONENTS and the benefits it brings in caching (see whole argument on EJB in BLUE). Putting EJB behind the whole mess would be great. PHP can talk java but it is out of process so that you go back to serialization and LOSE the benefit of caching. Period. So clearly having the PHP code interpreted in java would be great as you access the db data in cache. The problem is that the libraries used need to be ported too and that becomes a pain. I am really serious with the porting as Julien will be payed for this. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 6:20 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] PHP anybody thought about integrating php (and this way the cms-whatever-this-is thingy) into the the containers? maybe by calling the zend engine natively? layer rules ... just an idea .. bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing
Re[4]: [JBoss-dev] PHP
we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is provided by a HB SAPI module that interfaces with the Servlet server, the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +--+ | Zend Engine | +--+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +--+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt.| | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +--+ | Authors: Andi Gutmans [EMAIL PROTECTED]| | Zeev Suraski [EMAIL PROTECTED]| +--+ */ HB anybody thought about integrating php (and this way the cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
RE: [JBoss-dev] One thing I like about the Apache thing
zip) - done (redeployed) ... now if only some Atlanta company would show the money - hehe Dude, code like julien did and I will pay for your next development like I did with julien on the nukes on jboss thing peace, marcf /me --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Re[4]: [JBoss-dev] PHP
mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is provided by a HB SAPI module that interfaces with the Servlet server, the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +--+ | Zend Engine | +--+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +--+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt.| | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +--+ | Authors: Andi Gutmans [EMAIL PROTECTED]| | Zeev Suraski [EMAIL PROTECTED]| +--+ */ HB anybody thought about integrating php (and this way the cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried
[JBoss-dev] na(t)ive
hi all, with the php thing we are back to my favoured item: how do i describe and call a native method in the jboss semantic. same procedure as in the embedded world. any suggs? bax --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[2]: [JBoss-dev] PHP
what is the zend engine? marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of julien viet Sent: Thursday, January 09, 2003 6:27 PM To: Holger Baxmann Subject: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt. | | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +- -+ | Authors: Andi Gutmans [EMAIL PROTECTED] | | Zeev Suraski [EMAIL PROTECTED] | +- -+ */ HB anybody thought about integrating php (and this way the HB cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com
RE: Re[4]: [JBoss-dev] PHP
holger, we totally agree and we are talking about the same thing. I already proposed it to Julien back when we wanted to go PN. The idea is indeed to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache access. That is what it is all about and what is killing the current www.jboss.org machine under apache/php, the fact that PHP is a lot of servlet/jdbc equivalent code done poorly. Let's do a port for now, with EJB representing the tables so that at least we remove the JDBC code (or ODBC or whatever it is PHP uses) and leverage some cache. It will speed www.jboss.org speed by ten. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is HB provided by a SAPI module that interfaces with the Servlet server, HB the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt. | | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
Re[4]: [JBoss-dev] PHP
zend engine is PHP parser-compiler from zend company : www.zend.com now they are working on a version 2 with more robust object as said on their website. finally they'll have a true OOP language julien mf what is the zend engine? mf marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of julien viet Sent: Thursday, January 09, 2003 6:27 PM To: Holger Baxmann Subject: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt. | | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +- -+ | Authors: Andi Gutmans [EMAIL PROTECTED] | | Zeev Suraski [EMAIL PROTECTED] | +- -+ */ HB anybody thought about integrating php (and this way the HB cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf
Re: Re[2]: [JBoss-dev] PHP
the php 'vm' bax Von: marc fleury [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 19:31:26 -0500 An: [EMAIL PROTECTED] Betreff: RE: Re[2]: [JBoss-dev] PHP what is the zend engine? marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of julien viet Sent: Thursday, January 09, 2003 6:27 PM To: Holger Baxmann Subject: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt. | | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +- -+ | Authors: Andi Gutmans [EMAIL PROTECTED] | | Zeev Suraski [EMAIL PROTECTED] | +- -+ */ HB anybody thought about integrating php (and this way the HB cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing
Re: Re[4]: [JBoss-dev] PHP
finally they'll have a true OOP language OOP in this case: Other Orphaned Preprocessor ;-) bax julien mf what is the zend engine? mf marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of julien viet Sent: Thursday, January 09, 2003 6:27 PM To: Holger Baxmann Subject: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt. | | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +- -+ | Authors: Andi Gutmans [EMAIL PROTECTED] | | Zeev Suraski [EMAIL PROTECTED] | +- -+ */ HB anybody thought about integrating php (and this way the HB cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED]
RE: Re[4]: [JBoss-dev] PHP
I've been looking into this as you speak. Seems from reading doco that you can't go Java-PHP-Java which is what we need. Not sure what would happen if PHP called from Java created a JVM. Too bad there isn't a PHP Jython like thing Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, January 09, 2003 7:35 PM To: [EMAIL PROTECTED] Subject: RE: Re[4]: [JBoss-dev] PHP holger, we totally agree and we are talking about the same thing. I already proposed it to Julien back when we wanted to go PN. The idea is indeed to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache access. That is what it is all about and what is killing the current www.jboss.org machine under apache/php, the fact that PHP is a lot of servlet/jdbc equivalent code done poorly. Let's do a port for now, with EJB representing the tables so that at least we remove the JDBC code (or ODBC or whatever it is PHP uses) and leverage some cache. It will speed www.jboss.org speed by ten. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is HB provided by a SAPI module that interfaces with the Servlet server, HB the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject
Re: Re[4]: [JBoss-dev] PHP
I've been looking into this as you speak. Seems from reading doco that you can't go Java-PHP-Java which is what we need. Not sure what would happen if PHP called from Java created a JVM. Too bad there isn't a PHP Jython like thing have a look at the java sapi (server [sic!] application interface) and the servlet.java, there you can call the php engine - zend - out of a servlet container. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, January 09, 2003 7:35 PM To: [EMAIL PROTECTED] Subject: RE: Re[4]: [JBoss-dev] PHP holger, we totally agree and we are talking about the same thing. I already proposed it to Julien back when we wanted to go PN. The idea is indeed to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache access. That is what it is all about and what is killing the current www.jboss.org machine under apache/php, the fact that PHP is a lot of servlet/jdbc equivalent code done poorly. Let's do a port for now, with EJB representing the tables so that at least we remove the JDBC code (or ODBC or whatever it is PHP uses) and leverage some cache. It will speed www.jboss.org speed by ten. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is HB provided by a SAPI module that interfaces with the Servlet server, HB the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject to
Re: [JBoss-dev] na(t)ive
Its the same as any other JNI code. The only issue is that the jar that loads the shared library for the native code cannot be redeployed. I have not really looked into if this is a limitation of the JNI layer, or a JBoss class loading issue. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Holger Baxmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 4:33 PM Subject: [JBoss-dev] na(t)ive hi all, with the php thing we are back to my favoured item: how do i describe and call a native method in the jboss semantic. same procedure as in the embedded world. any suggs? bax --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossMQ
Hi, I am working on a new invocation layer (IL) for JbossMQ that encodes all communication in Xml (XIL). I've got the IL pretty near completion, and I am working on a C# jbossmq client. I am trying to develop the TopicSubsciber, which is an extension of MessageConsumer. In reviewing the code in the jbossmq java sources, it looks to me like the client to a topic actually runs a loop sending receive requests to the server regularly. Is this really necessary? Once the connection has been established, why can't the server just invoke the ClientIL.receive method (which actually sends the message to the client) when a message arrives at the destination? It looks to me like the current implementation is not truly asynchronous... What am I missing? Thanks, fawce - John Fawcett CTO, Tamale Software, LLC 26 Fox Road Waltham, MA 02451 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[4]: [JBoss-dev] PHP
Damn PHP install doesn't even work for the java stuff. Followed directions and can't get it to build. Now I'm hacking Makefiles :( -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 8:03 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP I've been looking into this as you speak. Seems from reading doco that you can't go Java-PHP-Java which is what we need. Not sure what would happen if PHP called from Java created a JVM. Too bad there isn't a PHP Jython like thing have a look at the java sapi (server [sic!] application interface) and the servlet.java, there you can call the php engine - zend - out of a servlet container. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, January 09, 2003 7:35 PM To: [EMAIL PROTECTED] Subject: RE: Re[4]: [JBoss-dev] PHP holger, we totally agree and we are talking about the same thing. I already proposed it to Julien back when we wanted to go PN. The idea is indeed to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache access. That is what it is all about and what is killing the current www.jboss.org machine under apache/php, the fact that PHP is a lot of servlet/jdbc equivalent code done poorly. Let's do a port for now, with EJB representing the tables so that at least we remove the JDBC code (or ODBC or whatever it is PHP uses) and leverage some cache. It will speed www.jboss.org speed by ten. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is HB provided by a SAPI module that interfaces with the Servlet server, HB the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project
Re[6]: [JBoss-dev] PHP
To my mind creating an PHP compiler/interpreter/whatever on a java VM is feasible but would require lot of resources. I did a pascal compiler in my early courses, but the context was very different. With pascal you have things that are well defined. PHP is another case : 1.there are no specificationsm the only thing we have is zend source code, blurred language definition. 2.it's a moving target now what *does matter* is to have a true CMS on java platform. The way above is one way and porting postnuke is another. I think that straight porting is really feasible, although I don't discard porting PHP sometimes later. julien mf holger, mf we totally agree and we are talking about the same thing. I already mf proposed it to Julien back when we wanted to go PN. The idea is indeed mf to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache mf access. That is what it is all about and what is killing the current mf www.jboss.org machine under apache/php, the fact that PHP is a lot of mf servlet/jdbc equivalent code done poorly. mf Let's do a port for now, with EJB representing the tables so that at mf least we remove the JDBC code (or ODBC or whatever it is PHP uses) and mf leverage some cache. It will speed www.jboss.org speed by ten. mf marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is HB provided by a SAPI module that interfaces with the Servlet server, HB the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine |
RE: Re[6]: [JBoss-dev] PHP
What about just writing a shell script to walk the tree of jboss.org via the PHP every x min or hours, spit out static HTML, and only offer paths to the PHP-based pages for POSTing of new forum stuff? Would that be a bit faster and reduce your server load at the PHP end for read-only stuff, before Julien gets everything ported for the long term solution? Just being creative here.. James --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[2]: [JBoss-dev] PHP
On Thu, 9 Jan 2003, marc fleury wrote: Nukes on JBoss is going to be SUCH A GREAT PROJECT. Finally ENTERPRISE CMS for the MASSES. Well, we have been playing with OFBiz(www.ofbiz.org) lately. It uses it's own entity engine(which I know you guys don't like), but their GenericValue objects are really easy to work with(no code to write). However, they have a very nice admin interface, and CMS. It's a full fledged shopping cart system. Products, categories, orders, tracking, warehousing, shipping. 450+ tables. Web template code, service engine, tons of stuff. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[6]: [JBoss-dev] PHP
Just thought it would be easier if you could run php-java-php then you could have a total working system that you port incrementally. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of julien viet Sent: Thursday, January 09, 2003 8:34 PM To: marc fleury Subject: Re[6]: [JBoss-dev] PHP To my mind creating an PHP compiler/interpreter/whatever on a java VM is feasible but would require lot of resources. I did a pascal compiler in my early courses, but the context was very different. With pascal you have things that are well defined. PHP is another case : 1.there are no specificationsm the only thing we have is zend source code, blurred language definition. 2.it's a moving target now what *does matter* is to have a true CMS on java platform. The way above is one way and porting postnuke is another. I think that straight porting is really feasible, although I don't discard porting PHP sometimes later. julien mf holger, mf we totally agree and we are talking about the same thing. I already mf proposed it to Julien back when we wanted to go PN. The idea is indeed mf to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache mf access. That is what it is all about and what is killing the current mf www.jboss.org machine under apache/php, the fact that PHP is a lot of mf servlet/jdbc equivalent code done poorly. mf Let's do a port for now, with EJB representing the tables so that at mf least we remove the JDBC code (or ODBC or whatever it is PHP uses) and mf leverage some cache. It will speed www.jboss.org speed by ten. mf marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is HB provided by a SAPI module that interfaces with the Servlet server, HB the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering
[JBoss-dev] [ jboss-Bugs-665394 ] MDB pool size is not bounded -- Is the max size being read?
Bugs item #665394, was opened at 2003-01-09 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665394group_id=22866 Category: JBossMQ Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Elias Ross (genman) Assigned to: Nobody/Anonymous (nobody) Summary: MDB pool size is not bounded -- Is the max size being read? Initial Comment: I don't really want to create 100 MDB for my application, so I changed the standardjboss.xml configuration (like I did in 3.2): --- standardjboss.xml Fri Dec 20 18:47:58 2002 +++ /home/eross/src/javapackages/jboss/server/default/conf/standardjboss.xml Thu Jan 9 14:22:38 2003 @@ -774,7 +774,7 @@ persistence-manager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager container-pool-conf -MaximumSize100/MaximumSize + MaximumSize5/MaximumSize /container-pool-conf /container-configuration This doesn't seem to work and I end up with hundreds of threads (and eventually run out of sockets...) Actually setting this number to -1 or something else doesn't create any error... I end up with this in the logs: 2003-01-09 22:32:54,997 ERROR [JMSContainerInvoker] Exception in JMSCI message listener javax.ejb.TransactionRolledbackLocalException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused); CausedByException is: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:311) at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:697) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:985) at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:241) at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:601) at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:415) at org.jboss.mq.SpySession.run(SpySession.java:293) at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655) at java.lang.Thread.run(Thread.java:536) javax.ejb.EJBException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) -- Comment By: Elias Ross (genman) Date: 2003-01-09 18:38 Message: Logged In: YES user_id=556458 In my application, I create a JMS connection in my ejbCreate() method. Apparently, this is where things start to get out of control... It appears to be a configuration error (*grin*) with how the JMS connection pool is larger than the MDB pool. (I was configuring things like I did in JBoss 3.0 to reduce the pool size.) If the MDB pool is too small, then new instances are always thrown away. This is a user area, but hard to diagnose. In such situations, I notice that ejbRemove() is never called for my MDB, even though there are literally hundreds of new instances apparently thrown out. I guess I'd like someone to verify that ejbRemove is eventually called for a MDB that's thrown out of the AbstractPool... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665394group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] One thing I like about the Apache thing
On Thu, 9 Jan 2003, marc fleury wrote: I was not aware of this. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: Thursday, January 09, 2003 6:00 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] One thing I like about the Apache thing It is already there. Many times I have gone in and edited the jboss.org site content in the unpacked war to pick it changes. Its not even a redeployment. The web container watches the timestamps on the web content. We use symlinks. the web.war is a symlink to www in the development folder. We never have to redeploy, just to update some silly jsp. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] na(t)ive
Hm...any ideas on how we might handle things like the -Xhprof argument, which has to be specified on JVM initalization? I've been holding off on a JVM Profiler MBean because the whole load-time issue defeats the point of even having the profiler interfaced as an MBean. -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Thu 1/9/2003 8:08 PM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] na(t)ive Its the same as any other JNI code. The only issue is that the jar that loads the shared library for the native code cannot be redeployed. I have not really looked into if this is a limitation of the JNI layer, or a JBoss class loading issue. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Holger Baxmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 4:33 PM Subject: [JBoss-dev] na(t)ive hi all, with the php thing we are back to my favoured item: how do i describe and call a native method in the jboss semantic. same procedure as in the embedded world. any suggs? bax --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development winmail.dat
[JBoss-dev] jboss configuration
Hi I am a newbie, i wish to configure JBOSS on my machine i downloaded jboss-3.0.4_tomcat-4.1.12.zip file but after extracting it and on running the run.bat file ho do i know that the server has actually started. i need to check for the JMS support in JBOSS. I would be grateful if any one can help me on this context Regards Saurabh
RE: [JBoss-dev] PHP
Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] One thing I like about the Apache thing
Amen. Having jsp pages just recompile with a browser reload would save an huge amount of development time... admit the nightmare of scalability with PN there is one thing that caught my eye. I really had forgotten how nice it is to edit a webpage and see it picked up live by the webserver. It sounds like nothing but we really lost something with this stupid EAR/WAR packaging nightmare. We already support exploded deployment. Is there a way we can do partial redeployment of at least the static pages in JBoss? So we can edit the page quick without having to redeploy the full site? If I am lost and it is already done let me know and I will be quiet. marcf xx Marc Fleury, Ph.D. President, Founder JBoss Group, LLC xx --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
Re[2]: [JBoss-dev] PHP
I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +--+ | Zend Engine | +--+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +--+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt.| | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +--+ | Authors: Andi Gutmans [EMAIL PROTECTED]| | Zeev Suraski [EMAIL PROTECTED]| +--+ */ HB anybody thought about integrating php (and this way the cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED]
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 11:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
Re: [JBoss-dev] PHP
anybody thought about integrating php (and this way the cms-whatever-this-is thingy) into the the containers? maybe by calling the zend engine natively? layer rules ... just an idea .. bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] PHP
Actually your idea does have merit. Julien. Maybe run PHP as a servlet and slowly replace PostNuke functionality with JSP/Java/EJB. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 6:20 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] PHP anybody thought about integrating php (and this way the cms-whatever-this-is thingy) into the the containers? maybe by calling the zend engine natively? layer rules ... just an idea .. bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=665183group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
[JBoss-dev] [ jboss-Bugs-665394 ] MDB pool size is not bounded -- Is the max size being read?
Bugs item #665394, was opened at 2003-01-09 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665394group_id=22866 Category: JBossMQ Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Elias Ross (genman) Assigned to: Nobody/Anonymous (nobody) Summary: MDB pool size is not bounded -- Is the max size being read? Initial Comment: I don't really want to create 100 MDB for my application, so I changed the standardjboss.xml configuration (like I did in 3.2): --- standardjboss.xml Fri Dec 20 18:47:58 2002 +++ /home/eross/src/javapackages/jboss/server/default/conf/standardjboss.xml Thu Jan 9 14:22:38 2003 @@ -774,7 +774,7 @@ persistence-manager/persistence-manager transaction-managerorg.jboss.tm.TxManager/transaction-manager container-pool-conf -MaximumSize100/MaximumSize + MaximumSize5/MaximumSize /container-pool-conf /container-configuration This doesn't seem to work and I end up with hundreds of threads (and eventually run out of sockets...) Actually setting this number to -1 or something else doesn't create any error... I end up with this in the logs: 2003-01-09 22:32:54,997 ERROR [JMSContainerInvoker] Exception in JMSCI message listener javax.ejb.TransactionRolledbackLocalException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused); CausedByException is: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:311) at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:697) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:985) at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:241) at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:601) at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:415) at org.jboss.mq.SpySession.run(SpySession.java:293) at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655) at java.lang.Thread.run(Thread.java:536) javax.ejb.EJBException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=665394group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re[2]: [JBoss-dev] PHP
Problem Bill, such a thing does not exists yet and that would be time consuming to start that from scratch. julien BB Actually your idea does have merit. Julien. Maybe run PHP as a servlet and BB slowly replace PostNuke functionality with JSP/Java/EJB. BB Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 6:20 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] PHP anybody thought about integrating php (and this way the cms-whatever-this-is thingy) into the the containers? maybe by calling the zend engine natively? layer rules ... just an idea .. bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development BB --- BB This SF.NET email is sponsored by: BB SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! BB http://www.vasoftware.com BB ___ BB Jboss-development mailing list BB [EMAIL PROTECTED] BB https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail :
[JBoss-dev] CMP incompatibility between 3.0.2 and 3.0.4
After upgrading from 3.0.2 to 3.0.4 it seems JBoss handles EJB properties of type Serializable in a different way. My whole solution is running the way it used to except for one thing: Those of my EJBs which have CMP fields which are of type serializable object fail. For instance, one of my beans has a field called validator which stores a serialized java object. After I started using JBoss 3.0.4 it was no longer possible to read these beans from the database. JBoss threw this exception: java.sql.SQLException: Got a [B[cl=0, value=[B@1ab7626] while looking for a dk.r ockit.puls.value.property.validator.Validator[cl=31889293] at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.coerceToJavaType(JDBCUtil.jav a:570) at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.getResult(JDBCUtil.java:437) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.load ArgumentResults(JDBCAbstractCMPFieldBridge.java:359) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.load InstanceResults(JDBCAbstractCMPFieldBridge.java:312) Extensive testing has shown that all EJBs which have a serializable object field with a non-null value cannot be read from or written to the database (a SAP DB). As another example, I have an EJB which has a field called menuBar which stores a serialized java object. When setting a non-null value for this field on my EJB I get the following exception: javax.ejb.EJBException: Internal error setting parameters for field menuBar; Cau sedByException is: Cannot put ASCII data into this long column at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setA rgumentParameters(JDBCAbstractCMPFieldBridge.java:297) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setI nstanceParameters(JDBCAbstractCMPFieldBridge.java:270) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.execute(JDBCSto reEntityCommand.java:85) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEntity(JDBCStore Manager.java:589) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity(CMPPersistenc eManager.java:458) Now, my database is exactly the same namely a SAP database, and I checked that the standardjbosscmp-jdbc configuration is also the same looking at the exception above it seems JBoss tries to store the object as a ascii string of some sort. Both my 3.0.2 and 3.0.4 has this setting mapping java-typejava.lang.Object/java-type jdbc-typeJAVA_OBJECT/jdbc-type sql-typeLONG BYTE/sql-type /mapping which is exactly the setting I want. I went as far as dropping the whole database and reconstructing it using the new 3.0.4 in hopes the error was caused by some inconsistency between the two versions no luck, the 3.0.4 is simply not able to handle my Serializable fields. If anyone has any idea what is different in JBoss 3.0.4 I shall be very pleased to hear from you. Finally I should mention that I based my 3.0.2 deployment on the all deployment configuration (with virtually no changes), and my 3.0.4 deployment is now based on the default deployment configuration (with virtually no changes). I did this to improve startup performance (it actually lowered the startup time by one third). Yours Randahl
