[JBoss-dev] HA for the lazy
Hello, For the laziest around here, I have compiled a ready-to-run version (based on 2.2.1 of the 17th of April 2001). You can read info on the web page or download it directly (you'll find a HADoc folder in it): - http://194.38.95.241/jboss/ - http://194.38.95.241/jboss/JBossHA2.2.1Release.zip In short, simply unzip the content on as many computer as you want, launch them, and launch a TestGUI.jar from one of these computers (in the bin folder). Cheers, Sacha - - - - - - - - - - - - - - - - - - - - - - Sacha Labourey Cogito Informatique Ing. Inf. Dipl. EPF4, Verger l'Ecuyer Tél +41 32 754 36 41 CH - 2068 Hauterive http://cogito-info.ch/ Fax +41 32 754 36 42 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] custom finders
Hi all!
Is there a possibilty to let the finder defined in jaws.xml interpret
a given PK-class (lets say PersonPK)?
Overwriting toString() has no effect!
example:
public class PersonPK impl java.io.Ser {
public String personID
}
AccountHome: findByPerson(PersonPK pk)
jaws.xml: where person = {0}.personID
Is something like that possible?
Thanx in advance
Torben
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] inheritance and ejb interfaces
Hello,
we can't work with super-interfaces of the home interfaces instead the home
interfaces itselfs. Is this a jBoss bug or is what we try to do against the
EJB 1.1 spec?
we have a group of EB's which have a set of equal business methods. We tried
to define a interface as super-interface for all this EB's. Also we need a
corresponding home interface with a findByPrimaryKey method.
RemoteInterface extends EJBObject {
retType someBusinessMethod();
}
MyEntity extends RemoteInterface {
}
and for the home infs:
HomeInterface extends EJBHome {
RemoteInterface findByPrimaryKey(String key);
}
MyHome extends HomeInterface {
MyHome create( ...
}
On the remote side this works but if we call the findByPrimaryKey method
jBoss throws an error.
HomeInterface parentHome =
(HomeInterface)initial.lookup(parentEntity); //thats ok!
RemoteInterface thisParent =
(RemoteInterface)parentHome.findByPrimaryKey(parentId); //but here ocure the
runtime error.
[EACMSession] call DataImpl.getInstance for class 'eacm.ejb.inf.Selection'.
[MarketDataInputEntity] TRANSACTION ROLLBACK EXCEPTION:result of finder
method is not a valid return type: class java.lang.String; nested exception
is:
java.rmi.RemoteException: result of finder method is not a valid
return type: class java.lang.String
[MarketDataInputEntity] java.rmi.RemoteException: result of finder method is
not a valid return type: class java.lang.String
[MarketDataInputEntity] at
org.jboss.ejb.plugins.BMPPersistenceManager.findEntities(BMPPersistenceManag
er.java:259)
[MarketDataInputEntity] at
org.jboss.ejb.EntityContainer.find(EntityContainer.java:392)
[MarketDataInputEntity] at java.lang.reflect.Method.invoke(Native
Method)
[MarketDataInputEntity] at
org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContaine
r.java:639)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySync
hronizationInterceptor.java:160)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInt
erceptor.java:87)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:135)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
java:263)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:86)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.jav
a:119)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:106)
[MarketDataInputEntity] at
org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:316)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invokeHome(JRMPContai
nerInvoker.java:424)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invoke(HomeProxy.java:198)
[MarketDataInputEntity] at $Proxy26.findByPrimaryKey(Unknown Source)
[MarketDataInputEntity] at
eacm.ejb.inf.Selection.init(Selection.java:61)
[MarketDataInputEntity] at
eacm.ejb.inf.Selection.(Selection.java:28)
[MarketDataInputEntity] at
java.lang.reflect.Constructor.newInstance(Native Method)
[MarketDataInputEntity] at
eacm.ejb.inf.DataImpl.getInstance(DataImpl.java:121)
[MarketDataInputEntity] at
eacm.ejb.EACMSessionBean.getData(EACMSessionBean.java:116)
[MarketDataInputEntity] at java.lang.reflect.Method.invoke(Native
Method)
[MarketDataInputEntity] at
org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invoke(StatefulS
essionContainer.java:570)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:13
7)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSess
ionInstanceInterceptor.java:206)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.java:133)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
java:263)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[MarketDataInputEntity] at
org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:
326)
[MarketDataInputEntity] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI
nvoker.java:384)
[MarketDataInputEntity] at java.lang.reflect.Method.invoke(Native
Method)
[MarketDataInputEntity] at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServe
RE: [JBoss-dev] DependencyManager & jboss.dependencies
Hi, On Mon, 16 Apr 2001, Jason Dillon wrote: > Any preferences on how to continue? My bias would be to commit these > changes soon, so I can move on to other bits. This will effect OpenJMS > users, so we should probably add that to a release note also. yeah I think you can commit it.. if people don't appreciate the changes, they will send angry emails to you about it, at which point you can consider undoing your changes.. :) anyway, I don't think there are that many JBoss/OpenJMS users out there and the code will still be available in the contrib/ module -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] nested field patch for JDBCFindByCommand
Hi!
Problems occurred when using feature automatically creating
findBy...-Methods with nested fields!
JDBCFindByCommand-constructor could not recognize cmp-fields which are
nested in data objects.
Following small JDBCFindByCommand-constructor patch works fine:
public JDBCFindByCommand(JDBCCommandFactory factory, Method finderMethod)
throws IllegalArgumentException
{
super(factory, finderMethod.getName());
String cmpFieldName = finderMethod.getName().substring(6).toLowerCase();
Logger.debug("Finder:"+cmpFieldName);
// Find the meta-info for the field we want to find by
cmpField = null;
Iterator iter = jawsEntity.getCMPFields();
while (cmpField == null && iter.hasNext())
{
CMPFieldMetaData fi = (CMPFieldMetaData)iter.next();
// pay attention when working with nested fields
// ergo, only compare lastComponent of fieldName
// if there is no nested field, there should also be
no conflict by comparing
// it this way, because getLastComponent() returns the
// parameter untouched
if
(cmpFieldName.equals(CMPFieldMetaData.getLastComponent(fi.getName()).toLowerCase()))
cmpField = fi;
}
if (cmpField == null)
{
throw new IllegalArgumentException(
"No finder for this method: " + finderMethod.getName());
}
// Compute SQL
String sql = "SELECT " + getPkColumnList() +
" FROM "+jawsEntity.getTableName()+ " WHERE ";
sql += cmpField.getColumnName() + "=?";
setSQL(sql);
}
Can this be added to repository because nested field support was
also added and this would be a step to completion of nested field
support (and I do not have to change it again if there will be - I
hope there will be ;) - future releases of jBoss)
Thanx
--
Torben Jäger
Orientation in Objects GmbH
http://www.oio.de
<< life is short - code hard >>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] HA for the lazy
Question:
Currently it looks like every remote call is load balanced with a round
robin algorithm.
What if the user initiates a transaction (user transaction) and the
transaction lasts over three method invokations.
If I have three servers clustered, this means that the invokation will
happen on one server for each call, and since the transactional information
may not be replicated, the client will get some funky results.
I think I'm telling the truth here :), because with JDBC when having a
transaction open, the EJB server has to reserve that connection until the
transaction is committed. And since the JDBC connection is pinned to one
server, if invoking a call on another server, you suddenly lose your
transactional context.
I would recommend that once you start making invokations on a bean, that you
pin the invokations to one server and don't switch server until the current
one is crashed.
just my $0.02
public ContainerRemote getRemoteTarget()
{
if (father.crs.length == 0)
{
findTargetsSynchronously ();
if (father.crs.length == 0)
return null;
}
synchronized (father.crs)
{
cursorRemote = ( (cursorRemote + 1) % father.crs.length );
return father.crs[cursorRemote];
}
}
~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/docs howtombeans.xml
User: alborini Date: 01/04/17 09:46:22 Modified:src/docs howtombeans.xml Log: typo Revision ChangesPath 1.5 +3 -3 manual/src/docs/howtombeans.xml Index: howtombeans.xml === RCS file: /cvsroot/jboss/manual/src/docs/howtombeans.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- howtombeans.xml 2001/04/04 02:43:21 1.4 +++ howtombeans.xml 2001/04/17 16:46:21 1.5 @@ -19,10 +19,10 @@ Parse the jboss.jcml file and instantiate all MBeans - Parse the optional jboss-auth.jcml + Parse the optional jboss-auto.jcml - If jboss-auth.jcml exists, parse the file and instantiate any MBeans that were not created by the parse of the jboss.jcml file. + If jboss-auto.jcml exists, parse the file and instantiate any MBeans that were not created by the parse of the jboss.jcml file. Apply the MBean attribute settings from the jboss-auto.jcml file. @@ -317,4 +317,4 @@ - \ No newline at end of file + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: manual/src/docs howtombeans.xml
Hey, Good catch. Should encourage other people to do the same. Any typos or incorrect information, just go in and correct it. On Tue, 17 Apr 2001 [EMAIL PROTECTED] wrote: > User: alborini > Date: 01/04/17 09:46:22 > > Modified:src/docs howtombeans.xml > Log: > typo > > Revision ChangesPath > 1.5 +3 -3 manual/src/docs/howtombeans.xml > > Index: howtombeans.xml > === > RCS file: /cvsroot/jboss/manual/src/docs/howtombeans.xml,v > retrieving revision 1.4 > retrieving revision 1.5 > diff -u -r1.4 -r1.5 > --- howtombeans.xml 2001/04/04 02:43:21 1.4 > +++ howtombeans.xml 2001/04/17 16:46:21 1.5 > @@ -19,10 +19,10 @@ > Parse the jboss.jcml file and >instantiate all MBeans > > > - Parse the optional jboss-auth.jcml > + Parse the optional jboss-auto.jcml > > > - If jboss-auth.jcml >exists, parse the file and instantiate any MBeans that were not created by the parse >of the jboss.jcml file. > + If jboss-auto.jcml >exists, parse the file and instantiate any MBeans that were not created by the parse >of the jboss.jcml file. > > > Apply the MBean >attribute settings from the jboss-auto.jcml file. > @@ -317,4 +317,4 @@ > > > > - > \ No newline at end of file > + > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Change Notes-416576 ] fixed race inTxCapsule
Hi Dan... --On Monday, April 16, 2001 6:49 PM -0700 [EMAIL PROTECTED] wrote: > Group: v2.2.1 Does this mean that this fix will be released with the 2.2.1 bug fix release this week? Thanks! Jim ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/docs howtombeans.xml
User: starksm Date: 01/04/17 10:24:42 Modified:src/docs howtombeans.xml Log: Update the non-ServiceMBeanSupport version to use System.out rather than the ServiceMBeanSupport log. Revision ChangesPath 1.6 +1 -1 manual/src/docs/howtombeans.xml Index: howtombeans.xml === RCS file: /cvsroot/jboss/manual/src/docs/howtombeans.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- howtombeans.xml 2001/04/17 16:46:21 1.5 +++ howtombeans.xml 2001/04/17 17:24:42 1.6 @@ -13,7 +13,7 @@ There are two classes of MBeans; those that are independent of JBoss services and those that are dependent on JBoss services. MBeans that are independent of JBoss services are the trival case and can be written per the JMX specification and added to a JBoss server by adding their MLET tag to the jboss.conf file. Writing an MBean that relies on a JBoss service like naming requires one to follow the JBoss service pattern. Before describing how to write such an MBean, let's go over the two JBoss services that manage the configuration and depdendencies of MBean services; ConfigurationService and ServiceControl. The ConfigurationService MBean - JBoss manages configuration its MBean services via a custom MBean that loads an xml variation of the standard MLet configuration file. This custom MBean is implemented in the org.jboss.configuration.ConfigurationService class. The ConfigurationService MBean is loaded when JBoss starts up by the JMX MLet due to its entry in the jboss.conf file. The jboss.jcml configuration is then loaded by invoking loadConfiguration() on the ConfigurationService MBean. The loadConfiguratoin method performs the following steps: + JBoss manages configuration its MBean services via a custom MBean that loads an xml variation of the standard MLet configuration file. This custom MBean is implemented in the org.jboss.configuration.ConfigurationService class. The ConfigurationService MBean is loaded when JBoss starts up by the JMX MLet due to its entry in the jboss.conf file. The jboss.jcml configuration is then loaded by invoking loadConfiguration() on the ConfigurationService MBean. The loadConfiguration method performs the following steps: Parse the jboss.jcml file and instantiate all MBeans ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Change Notes-416576 ] fixed race inTxCapsule
Yes. Scott was planning on packaging that up tommorrow or so. Jim Archer wrote: > > Hi Dan... > > --On Monday, April 16, 2001 6:49 PM -0700 [EMAIL PROTECTED] wrote: > > > Group: v2.2.1 > > Does this mean that this fix will be released with the 2.2.1 bug fix > release this week? > > Thanks! > > Jim > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] nested field patch for JDBCFindByCommand
Please submit patches here:
https://sourceforge.net/tracker/?func=add&group_id=22866&atid=376687
Thanks,
-- Juha
At 17:52 17.4.2001 +0200, you wrote:
>Hi!
>
>Problems occurred when using feature automatically creating
>findBy...-Methods with nested fields!
>JDBCFindByCommand-constructor could not recognize cmp-fields which are
>nested in data objects.
>
>Following small JDBCFindByCommand-constructor patch works fine:
>
> public JDBCFindByCommand(JDBCCommandFactory factory, Method finderMethod)
> throws IllegalArgumentException
> {
> super(factory, finderMethod.getName());
>
> String cmpFieldName =
finderMethod.getName().substring(6).toLowerCase();
> Logger.debug("Finder:"+cmpFieldName);
>
> // Find the meta-info for the field we want to find by
>
> cmpField = null;
> Iterator iter = jawsEntity.getCMPFields();
>
> while (cmpField == null && iter.hasNext())
> {
> CMPFieldMetaData fi = (CMPFieldMetaData)iter.next();
>
>
> // pay attention when working with nested fields
>// ergo, only compare lastComponent of fieldName
>// if there is no nested field, there should also be
>no conflict by
comparing
>// it this way, because getLastComponent() returns the
>// parameter untouched
>if
(cmpFieldName.equals(CMPFieldMetaData.getLastComponent(fi.getName()).toLower
Case()))
>cmpField = fi;
> }
>
>
> if (cmpField == null)
> {
> throw new IllegalArgumentException(
>"No finder for this method: " + finderMethod.getName());
> }
>
> // Compute SQL
>
> String sql = "SELECT " + getPkColumnList() +
> " FROM "+jawsEntity.getTableName()+ " WHERE ";
>
> sql += cmpField.getColumnName() + "=?";
>
> setSQL(sql);
> }
>
>Can this be added to repository because nested field support was
>also added and this would be a step to completion of nested field
>support (and I do not have to change it again if there will be - I
>hope there will be ;) - future releases of jBoss)
>
>Thanx
>
>--
>Torben Jäger
>Orientation in Objects GmbH
>http://www.oio.de
>
><< life is short - code hard >>
>
>
>___
>Jboss-development mailing list
>[EMAIL PROTECTED]
>http://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
User: starksm
Date: 01/04/17 12:33:09
Modified:src/main/org/jboss/metadata ApplicationMetaData.java
Log:
Remove the requirement that the res-jndi-name be prefixed with java:
Revision ChangesPath
1.14 +1 -5 jboss/src/main/org/jboss/metadata/ApplicationMetaData.java
Index: ApplicationMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ApplicationMetaData.java 2001/02/27 16:37:53 1.13
+++ ApplicationMetaData.java 2001/04/17 19:33:09 1.14
@@ -27,7 +27,7 @@
* @see
* @author mailto:[EMAIL PROTECTED]">Sebastien Alborini
* @author Peter Antman ([EMAIL PROTECTED])
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.14 $
*/
public class ApplicationMetaData extends MetaData {
// Constants -
@@ -334,10 +334,6 @@
String jndi = getElementContent(getOptionalChild(resourceManager,
"res-jndi-name"));
- // Make sure it is prefixed with java:
- if (jndi != null && !jndi.startsWith("java:/"))
- jndi = "java:/"+jndi;
-
String url = getElementContent(getOptionalChild(resourceManager,
"res-url"));
if (jndi != null && url == null) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
User: starksm
Date: 01/04/17 12:36:37
Modified:src/main/org/jboss/metadata Tag: Branch_2_2
ApplicationMetaData.java
Log:
Remove the requirement that the res-jndi-name be prefixed with java:
Revision ChangesPath
No revision
No revision
1.13.2.1 +1 -5 jboss/src/main/org/jboss/metadata/ApplicationMetaData.java
Index: ApplicationMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java,v
retrieving revision 1.13
retrieving revision 1.13.2.1
diff -u -r1.13 -r1.13.2.1
--- ApplicationMetaData.java 2001/02/27 16:37:53 1.13
+++ ApplicationMetaData.java 2001/04/17 19:36:37 1.13.2.1
@@ -27,7 +27,7 @@
* @see
* @author mailto:[EMAIL PROTECTED]">Sebastien Alborini
* @author Peter Antman ([EMAIL PROTECTED])
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.13.2.1 $
*/
public class ApplicationMetaData extends MetaData {
// Constants -
@@ -334,10 +334,6 @@
String jndi = getElementContent(getOptionalChild(resourceManager,
"res-jndi-name"));
- // Make sure it is prefixed with java:
- if (jndi != null && !jndi.startsWith("java:/"))
- jndi = "java:/"+jndi;
-
String url = getElementContent(getOptionalChild(resourceManager,
"res-url"));
if (jndi != null && url == null) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-416812 ] Removed res-jndi-name java: prefix need
Change Notes item #416812, was updated on 2001-04-17 12:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416812&group_id=22866 Category: None Group: v2.2.1 Status: Open Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Removed res-jndi-name java: prefix need Initial Comment: Fixed bug #414854. The requirement that the res-jndi-name be prefixed with java: has been removed from the ApplicationMetaData class. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416812&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
User: starksm
Date: 01/04/17 12:52:21
Modified:src/main/org/jboss/metadata ApplicationMetaData.java
Log:
Add an author tag for me
Revision ChangesPath
1.15 +2 -1 jboss/src/main/org/jboss/metadata/ApplicationMetaData.java
Index: ApplicationMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- ApplicationMetaData.java 2001/04/17 19:33:09 1.14
+++ ApplicationMetaData.java 2001/04/17 19:52:21 1.15
@@ -27,7 +27,8 @@
* @see
* @author mailto:[EMAIL PROTECTED]">Sebastien Alborini
* @author Peter Antman ([EMAIL PROTECTED])
- * @version $Revision: 1.14 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.15 $
*/
public class ApplicationMetaData extends MetaData {
// Constants -
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-416817 ] jnp JNDI provider url behavior issue
Bugs item #416817, was updated on 2001-04-17 12:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=416817&group_id=22866 Category: JBossServer Group: v2.3 (unstable) Status: Open Resolution: None Priority: 3 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: jnp JNDI provider url behavior issue Initial Comment: The jnp JNDI provider does not return subcontexts when given a Context.PROVIDER_URL that refers to a subcontext. For example: localhost:1199/topic does not return the topic Context as it should. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=416817&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: CVSROOT cvswrappers
User: user57 Date: 01/04/17 13:10:10 Modified:.cvswrappers Log: o Added some more binary file extentions: Archives - .rar, .ear, .war, .tar, .tgz, .gz Documents - .pdf Revision ChangesPath 1.3 +9 -0 CVSROOT/cvswrappers Index: cvswrappers === RCS file: /cvsroot/jboss/CVSROOT/cvswrappers,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- cvswrappers 1999/10/13 20:57:13 1.2 +++ cvswrappers 2001/04/17 20:10:10 1.3 @@ -21,9 +21,18 @@ # and value is a single-quote delimited value. # For example: #*.gif -k 'b' + *.gif -k 'b' -m 'COPY' *.jpg -k 'b' -m 'COPY' *.jpeg -k 'b' -m 'COPY' *.class -k 'b' -m 'COPY' *.jar -k 'b' -m 'COPY' *.zip -k 'b' -m 'COPY' +*.rar-k 'b' -m 'COPY' +*.ear-k 'b' -m 'COPY' +*.war-k 'b' -m 'COPY' +*.tar-k 'b' -m 'COPY' +*.tgz-k 'b' -m 'COPY' +*.gz -k 'b' -m 'COPY' +*.pdf-k 'b' -m 'COPY' + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Change Notes-416812 ] Removed res-jndi-name java: prefix need
Is it possible that people upgrading will need to put the 'java:' back into their res-jndi-names where appropriate? [EMAIL PROTECTED] wrote: > > Change Notes item #416812, was updated on 2001-04-17 12:47 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416812&group_id=22866 > > Category: None > Group: v2.2.1 > Status: Open > Priority: 5 > Submitted By: Scott M Stark (starksm) > Assigned to: Nobody/Anonymous (nobody) > Summary: Removed res-jndi-name java: prefix need > > Initial Comment: > Fixed bug #414854. > The requirement that the res-jndi-name be prefixed > with java: has been removed from the > ApplicationMetaData class. > > -- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416812&group_id=22866 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
On Tue, Apr 17, 2001 at 12:36:38PM -0700, [EMAIL PROTECTED] wrote: > User: starksm > Date: 01/04/17 12:36:37 > > Modified:src/main/org/jboss/metadata Tag: Branch_2_2 > ApplicationMetaData.java > Log: > Remove the requirement that the res-jndi-name be prefixed with java: This could break applications that used to work, right? Is this really a "bug" that needs to be fixed for 2.2? I absolutely agree that it's a good idea in 2.3. If this is going into 2.2, shouldn't the change note at least warn people that it might break things? Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src/build - New directory
User: user57 Date: 01/04/17 13:27:09 contrib/openjms/src/build - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src/main/org/jboss - New directory
User: user57 Date: 01/04/17 13:27:42 contrib/openjms/src/main/org/jboss - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src/lib - New directory
User: user57 Date: 01/04/17 13:27:10 contrib/openjms/src/lib - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src/main/org/jboss/jms/openjms - New directory
User: user57 Date: 01/04/17 13:27:42 contrib/openjms/src/main/org/jboss/jms/openjms - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src/main/org - New directory
User: user57 Date: 01/04/17 13:27:42 contrib/openjms/src/main/org - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src/main/org/jboss/jms - New directory
User: user57 Date: 01/04/17 13:27:42 contrib/openjms/src/main/org/jboss/jms - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src - New directory
User: user57 Date: 01/04/17 13:26:45 contrib/openjms/src - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src/main - New directory
User: user57 Date: 01/04/17 13:27:10 contrib/openjms/src/main - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms - New directory
User: user57 Date: 01/04/17 13:26:22 contrib/openjms - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src/lib exolabcore-0.1.jar openjms-client-patched-0.5.1.jar openjms-patched-0.5.1.jar openjms-pool.jar openjms-rmi-patched-0.5.1.jar
User: user57 Date: 01/04/17 13:33:43 Added: openjms/src/lib exolabcore-0.1.jar openjms-client-patched-0.5.1.jar openjms-patched-0.5.1.jar openjms-pool.jar openjms-rmi-patched-0.5.1.jar Log: o Migration of OpenJMS specific JBoss JMS provider classes from the main 'jboss'. NOTE: The migrated classes have been consolidated into one package. Revision ChangesPath 1.1 contrib/openjms/src/lib/exolabcore-0.1.jar <> 1.1 contrib/openjms/src/lib/openjms-client-patched-0.5.1.jar <> 1.1 contrib/openjms/src/lib/openjms-patched-0.5.1.jar <> 1.1 contrib/openjms/src/lib/openjms-pool.jar <> 1.1 contrib/openjms/src/lib/openjms-rmi-patched-0.5.1.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src/build build.sh build.xml
User: user57
Date: 01/04/17 13:33:42
Added: openjms/src/build build.sh build.xml
Log:
o Migration of OpenJMS specific JBoss JMS provider classes from the
main 'jboss'.
NOTE: The migrated classes have been consolidated into one package.
Revision ChangesPath
1.1 contrib/openjms/src/build/build.sh
Index: build.sh
===
#! /bin/sh
# $Id: build.sh,v 1.1 2001/04/17 20:33:42 user57 Exp $
PROGNAME=`basename $0`
DIRNAME=`dirname $0`
die() {
echo "${PROGNAME}: $*"
exit 1
}
#
# Must have JBOSS_HOME, so we know where to find some required library
# files.
#
if [ "x$JBOSS_HOME" = "x" ]; then
die "JBOSS_HOME is not set. Requires JBoss >= 2.2"
fi
exec ant -Djboss.home=$JBOSS_HOME \
-buildfile $DIRNAME/build.xml "$@"
1.1 contrib/openjms/src/build/build.xml
Index: build.xml
===
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms README
User: user57 Date: 01/04/17 13:33:42 Added: openjms README Log: o Migration of OpenJMS specific JBoss JMS provider classes from the main 'jboss'. NOTE: The migrated classes have been consolidated into one package. Revision ChangesPath 1.1 contrib/openjms/README Index: README === JBoss-OpenJMS --- This is a module that allows OpenJMS to be used as a JMS provider inside of JBoss. Building -- To build the provider module, you will need to have ANT >= v1.2 installed and a distribution of JBoss >= v2.2. 1) Set JBOSS_HOME to the directory where JBoss >= 2.2 has been extracted into: > export JBOSS_HOME= or > setenv JBOSS_HOME 2) Execute the build script under /src/build: > ./src/build/build.sh This should build a openjms-provider.jar, which contains the required class files to use OpenJMS as a JMS provider. Installing Once you have built the provder sources, you will need to update your JBoss installation to have the correct classes. 1) Copy the openjms-provider.jar to $JBOSS_HOME/lib/ext: > cp build/lib/openjms-provider.jar $JBOSS_HOME/lib/ext 2) Copy the OpenJMS support jars to $JBOSS_HOME/lib/ext > cp src/lib/*.jar $JBOSS_HOME/lib/ext Configuration --- Refer to the online documentation at: http://jboss.org/documentation/HTML/index.html for detailed instructions on how to setup a JMS provider. This is currently listed under "Working with Message Driven Beans". Problems -- JBoss questions should be directed to [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/openjms/src/main/org/jboss/jms/openjms OpenJMSProvider.java OpenJMSServerSessionPoolFactory.java package.html
User: user57
Date: 01/04/17 13:33:43
Added: openjms/src/main/org/jboss/jms/openjms OpenJMSProvider.java
OpenJMSServerSessionPoolFactory.java package.html
Log:
o Migration of OpenJMS specific JBoss JMS provider classes from the
main 'jboss'.
NOTE: The migrated classes have been consolidated into one package.
Revision ChangesPath
1.1
contrib/openjms/src/main/org/jboss/jms/openjms/OpenJMSProvider.java
Index: OpenJMSProvider.java
===
/**
* Copyright (c) 2000 Peter Antman Tim <[EMAIL PROTECTED]>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
package org.jboss.jms.openjms;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import org.jboss.logging.Logger;
import org.jboss.jms.jndi.AbstractJMSProviderAdapter;
/**
* A JMS provider adapter for OpenJMS.
*
* Created: Wed Nov 29 14:19:42 2000
*
* @author Peter Antman Tim ([EMAIL PROTECTED])
* @version
*/
public class OpenJMSProvider
extends AbstractJMSProviderAdapter
{
public static final String TOPIC_CONNECTION_FACTORY =
"JmsTopicConnectionFactory";
public static final String QUEUE_CONNECTION_FACTORY =
"JmsQueueConnectionFactory";
public static final String INITIAL_CONTEXT_FACTORY =
"org.exolab.jms.jndi.rmi.RmiJndiInitialContextFactory";
private static final String HOST_PROP_NAME =
"org.exolab.jms.jndi.Host";
private static final String PORT_PROP_NAME =
"org.exolab.jms.jndi.PortNumber";
private static final String SECURITY_MANAGER =
"java.naming.rmi.security.manager";
private String hasJndiSecurityManager = "yes";
public OpenJMSProvider() {
super(QUEUE_CONNECTION_FACTORY, TOPIC_CONNECTION_FACTORY);
}
public Context getInitialContext() throws NamingException {
// Have to parse url!!
Context context = null;
Hashtable props = new Hashtable();
props.put(Context.INITIAL_CONTEXT_FACTORY, INITIAL_CONTEXT_FACTORY);
props.put(HOST_PROP_NAME, "localhost");
Logger.debug("OpenJMSProvider: " + HOST_PROP_NAME + ":localhost");
props.put(PORT_PROP_NAME, new Integer(1199));
Logger.debug("OpenJMSProvider: " + PORT_PROP_NAME + 1199);
//props.put(Context.PROVIDER_URL, jndiProviderUrl);
props.put(SECURITY_MANAGER, hasJndiSecurityManager);
// props.put(Context.URL_PKG_PREFIXES, jndiPkgPrefixes);
return context = new InitialContext(props);
}
}
1.1
contrib/openjms/src/main/org/jboss/jms/openjms/OpenJMSServerSessionPoolFactory.java
Index: OpenJMSServerSessionPoolFactory.java
===
/*
* Copyright (c) 2000 Peter Antman Tim <[EMAIL PROTECTED]>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
package org.jboss.jms.openjms;
import java.util.Hashtable;
import javax.jms.Connection;
import javax.jms.MessageListener;
import javax.jms.ServerSessionPool;
import javax.jms.JMSException;
// Its in that package, but belongs to jboss ;-)
import org.exolab.jms.client.OpenJMSServerSessionPool;
import org.exolab.jms.client.JmsServerSessionPool;
import org.exolab.
RE: [JBoss-dev] [ jboss-Change Notes-416812 ] Removed res-jndi-namejava: prefix need
Yup, Especially those of us that are using direct SQL calls using the connection pools. Am I correct here? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of danch Sent: Tuesday, April 17, 2001 4:09 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] [ jboss-Change Notes-416812 ] Removed res-jndi-namejava: prefix need Is it possible that people upgrading will need to put the 'java:' back into their res-jndi-names where appropriate? [EMAIL PROTECTED] wrote: > > Change Notes item #416812, was updated on 2001-04-17 12:47 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416812&group_id= 22866 > > Category: None > Group: v2.2.1 > Status: Open > Priority: 5 > Submitted By: Scott M Stark (starksm) > Assigned to: Nobody/Anonymous (nobody) > Summary: Removed res-jndi-name java: prefix need > > Initial Comment: > Fixed bug #414854. > The requirement that the res-jndi-name be prefixed > with java: has been removed from the > ApplicationMetaData class. > > -- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416812&group_id= 22866 > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Change Notes-416812 ] Removed res-jndi-name java: prefix need
Yes if names without a java: are being used they will have to be added. - Original Message - From: "danch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 17, 2001 1:08 PM Subject: Re: [JBoss-dev] [ jboss-Change Notes-416812 ] Removed res-jndi-name java: prefix need > Is it possible that people upgrading will need to put the 'java:' back > into their res-jndi-names where appropriate? > > [EMAIL PROTECTED] wrote: > > > > Change Notes item #416812, was updated on 2001-04-17 12:47 > > You can respond by visiting: > > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416812&group_id=22866 > > > > Category: None > > Group: v2.2.1 > > Status: Open > > Priority: 5 > > Submitted By: Scott M Stark (starksm) > > Assigned to: Nobody/Anonymous (nobody) > > Summary: Removed res-jndi-name java: prefix need > > > > Initial Comment: > > Fixed bug #414854. > > The requirement that the res-jndi-name be prefixed > > with java: has been removed from the > > ApplicationMetaData class. > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
I think it is a bug for 2.2 as I cannot run the current ENC naming tests that need to access the JMS queue/topic factories because of this issue. I'll update the change note to include more details. - Original Message - From: "Toby Allsopp" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 17, 2001 1:14 PM Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java > On Tue, Apr 17, 2001 at 12:36:38PM -0700, [EMAIL PROTECTED] wrote: > > User: starksm > > Date: 01/04/17 12:36:37 > > > > Modified:src/main/org/jboss/metadata Tag: Branch_2_2 > > ApplicationMetaData.java > > Log: > > Remove the requirement that the res-jndi-name be prefixed with java: > > This could break applications that used to work, right? Is this really a "bug" > that needs to be fixed for 2.2? > > I absolutely agree that it's a good idea in 2.3. If this is going into 2.2, > shouldn't the change note at least warn people that it might break things? > > Toby. > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadataApplicationMetaData.java
Can this change be postponed? Some of us are using code generators and it would be more than a simple search/replace exercise to accomadate this. Or, is it possible to set the code such that it works with or without the java: prefix? Jim --On Wednesday, April 18, 2001 8:14 AM +1200 Toby Allsopp <[EMAIL PROTECTED]> wrote: > On Tue, Apr 17, 2001 at 12:36:38PM -0700, [EMAIL PROTECTED] > wrote: >> User: starksm >> Date: 01/04/17 12:36:37 >> >> Modified:src/main/org/jboss/metadata Tag: Branch_2_2 >> ApplicationMetaData.java >> Log: >> Remove the requirement that the res-jndi-name be prefixed with java: > > This could break applications that used to work, right? Is this really a > "bug" that needs to be fixed for 2.2? > > I absolutely agree that it's a good idea in 2.3. If this is going into > 2.2, shouldn't the change note at least warn people that it might break > things? > > Toby. > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
On Tue, Apr 17, 2001 at 01:50:16PM -0700, Scott M Stark wrote: > I think it is a bug for 2.2 as I cannot run the current ENC naming tests that > need to access the JMS queue/topic factories because of this issue. I'll > update the change note to include more details. Ah, that makes sense. I just hope you're prepared for the flood of people who suddenly can't use their DataSources :-). Hopefully the change note tracker will help to avoid this. Toby. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadataApplicationMetaData.java
Your code itself shouldn't change. I believe that it will just be places where you're mapping resource references in jboss.xml that would change, or have I misinterpreted, Scott? Jim Archer wrote: > > Can this change be postponed? Some of us are using code generators and it > would be more than a simple search/replace exercise to accomadate this. > > Or, is it possible to set the code such that it works with or without the > java: prefix? > > Jim > > --On Wednesday, April 18, 2001 8:14 AM +1200 Toby Allsopp > <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 17, 2001 at 12:36:38PM -0700, [EMAIL PROTECTED] > > wrote: > >> User: starksm > >> Date: 01/04/17 12:36:37 > >> > >> Modified:src/main/org/jboss/metadata Tag: Branch_2_2 > >> ApplicationMetaData.java > >> Log: > >> Remove the requirement that the res-jndi-name be prefixed with java: > > > > This could break applications that used to work, right? Is this really a > > "bug" that needs to be fixed for 2.2? > > > > I absolutely agree that it's a good idea in 2.3. If this is going into > > 2.2, shouldn't the change note at least warn people that it might break > > things? > > > > Toby. > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
I don't have a strong opinion on its inclusion so if in general this is going to cause more problems then it solves it can be left out of the 2.2.1 release. An ApplicationMetaData level compatability flag could be added to indicate whether the java:/ prefix should be assumed and this could be made true by default in 2.2.1. I don't know that this should be mantained in the main branch as using the full JNDI name that includes the java:/ prefix works and that it could be left off is not documented anywhere that I can find. - Original Message - From: "Jim Archer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 17, 2001 1:49 PM Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java > Can this change be postponed? Some of us are using code generators and it > would be more than a simple search/replace exercise to accomadate this. > > Or, is it possible to set the code such that it works with or without the > java: prefix? > > Jim > > --On Wednesday, April 18, 2001 8:14 AM +1200 Toby Allsopp > <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 17, 2001 at 12:36:38PM -0700, [EMAIL PROTECTED] > > wrote: > >> User: starksm > >> Date: 01/04/17 12:36:37 > >> > >> Modified:src/main/org/jboss/metadata Tag: Branch_2_2 > >> ApplicationMetaData.java > >> Log: > >> Remove the requirement that the res-jndi-name be prefixed with java: > > > > This could break applications that used to work, right? Is this really a > > "bug" that needs to be fixed for 2.2? > > > > I absolutely agree that it's a good idea in 2.3. If this is going into > > 2.2, shouldn't the change note at least warn people that it might break > > things? > > > > Toby. > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] exolabcore-0.1.jar
Does anyone know if exolabcore-0.1.jar is used by anything other than OpenJMS? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Change Notes-416812 ] Removed res-jndi-namejava: prefix need
A change will be required if you have a res-jndi-name element in your jboss.xml descriptor that is relying on the implied java:/ prefix being added. For example if your using: DefaultDS DefaultDS rather than: DefaultDS java:/DefaultDS the descriptor will be broken. - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 17, 2001 1:35 PM Subject: RE: [JBoss-dev] [ jboss-Change Notes-416812 ] Removed res-jndi-namejava: prefix need > Yup, > > Especially those of us that are using direct SQL calls using the connection > pools. Am I correct here? > > Bill > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib openjms-client-patched-0.5.1.jar openjms-patched-0.5.1.jar openjms-pool.jar openjms-rmi-patched-0.5.1.jar
User: user57 Date: 01/04/17 14:27:14 Removed: src/lib openjms-client-patched-0.5.1.jar openjms-patched-0.5.1.jar openjms-pool.jar openjms-rmi-patched-0.5.1.jar Log: o Removing files OpenJMS specific files that have been migrated to the contrib/openjms CVS module. o Added AbstractJMSProviderAdapter, which provides most of the bits that are required to implement a JMS provider. o Modified JBossMQProvider (and OpenJMSProvider in contrib/openjms) to extend AbstractJMSProviderAdapter. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
User: user57 Date: 01/04/17 14:27:14 Modified:src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java Log: o Removing files OpenJMS specific files that have been migrated to the contrib/openjms CVS module. o Added AbstractJMSProviderAdapter, which provides most of the bits that are required to implement a JMS provider. o Modified JBossMQProvider (and OpenJMSProvider in contrib/openjms) to extend AbstractJMSProviderAdapter. Revision ChangesPath 1.9 +1 -4 jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java Index: JMSContainerInvoker.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- JMSContainerInvoker.java 2001/03/02 14:57:57 1.8 +++ JMSContainerInvoker.java 2001/04/17 21:27:14 1.9 @@ -45,11 +45,8 @@ import org.jboss.jms.jndi.JMSProviderAdapter; import org.jboss.jms.asf.ServerSessionPoolFactory; -import org.exolab.jms.client.JmsServerSessionPool; - import org.w3c.dom.Element; -//import org.exolab.jms.jndi.JndiConstants; /** * ContainerInvoker for JMS MessageDrivenBeans, based on JRMPContainerInvoker. * @@ -59,7 +56,7 @@ * @author Rickard Öberg ([EMAIL PROTECTED]) * @author mailto:[EMAIL PROTECTED]">Sebastien Alborini * @author mailto:[EMAIL PROTECTED]">Marc Fleury - * @version $Revision: 1.8 $ + * @version $Revision: 1.9 $ */ public class JMSContainerInvoker implements ContainerInvoker, XmlLoadable ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/jndi AbstractJMSProviderAdapter.java JBossMQProvider.java OpenJMSProvider.java
User: user57
Date: 01/04/17 14:27:14
Modified:src/main/org/jboss/jms/jndi JBossMQProvider.java
Added: src/main/org/jboss/jms/jndi AbstractJMSProviderAdapter.java
Removed: src/main/org/jboss/jms/jndi OpenJMSProvider.java
Log:
o Removing files OpenJMS specific files that have been migrated to the
contrib/openjms CVS module.
o Added AbstractJMSProviderAdapter, which provides most of the bits that
are required to implement a JMS provider.
o Modified JBossMQProvider (and OpenJMSProvider in contrib/openjms) to
extend AbstractJMSProviderAdapter.
Revision ChangesPath
1.3 +25 -33jboss/src/main/org/jboss/jms/jndi/JBossMQProvider.java
Index: JBossMQProvider.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jms/jndi/JBossMQProvider.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JBossMQProvider.java 2001/02/28 09:25:46 1.2
+++ JBossMQProvider.java 2001/04/17 21:27:14 1.3
@@ -22,53 +22,45 @@
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
+
/**
- * JBossMQProvider.java
- *
+ * A JMS provider adapter for JBossMQ.
*
* Created: Fri Dec 22 09:34:04 2000
*
* @author Peter Antman
* @version
*/
-
-public class JBossMQProvider implements JMSProviderAdapter, java.io.Serializable{
-public static final String TOPIC_CONNECTION_FACTORY="XATopicConnectionFactory";
-public static final String QUEUE_CONNECTION_FACTORY="XAQueueConnectionFactory";
+public class JBossMQProvider
+ extends AbstractJMSProviderAdapter
+{
+public static final String TOPIC_CONNECTION_FACTORY =
"XATopicConnectionFactory";
+public static final String QUEUE_CONNECTION_FACTORY =
"XAQueueConnectionFactory";
public static final String INITIAL_CONTEXT_FACTORY =
"org.jnp.interfaces.NamingContextFactory";
public static final String URL_PKG_PREFIXES = "org.jboss.naming";
-private static final String SECURITY_MANAGER="java.naming.rmi.security.manager";
+private static final String SECURITY_MANAGER =
"java.naming.rmi.security.manager";
private String hasJndiSecurityManager = "yes";
-private String name;
-private String url;
+
public JBossMQProvider() {
-
+super(QUEUE_CONNECTION_FACTORY, TOPIC_CONNECTION_FACTORY);
}
-
-public void setProviderUrl(String url) {
- this.url = url;
-}
-public String getProviderUrl() { return url;}
-public void setName(String name) {this.name = name;}
-public String getName() {return name;}
public Context getInitialContext() throws NamingException {
- Context ctx = null;
- if (url == null) {
- // Use default
- ctx = new InitialContext();//Only for Jboss embedded now
- } else {
- //Try another location
- Hashtable props = new Hashtable();
- props.put(Context.INITIAL_CONTEXT_FACTORY, INITIAL_CONTEXT_FACTORY);
- props.put(Context.PROVIDER_URL, url);
- props.put(SECURITY_MANAGER, hasJndiSecurityManager);
- props.put(Context.URL_PKG_PREFIXES, URL_PKG_PREFIXES);
- ctx = new InitialContext(props);
- }
- return ctx;
+Context ctx = null;
+if (providerURL == null) {
+// Use default
+ctx = new InitialContext(); // Only for JBoss embedded now
+} else {
+// Try another location
+Hashtable props = new Hashtable();
+props.put(Context.INITIAL_CONTEXT_FACTORY, INITIAL_CONTEXT_FACTORY);
+props.put(Context.PROVIDER_URL, providerURL);
+props.put(SECURITY_MANAGER, hasJndiSecurityManager);
+props.put(Context.URL_PKG_PREFIXES, URL_PKG_PREFIXES);
+ctx = new InitialContext(props);
+}
+return ctx;
}
-public String getTopicFactoryName(){return TOPIC_CONNECTION_FACTORY;}
-public String getQueueFactoryName(){return QUEUE_CONNECTION_FACTORY;}
+
} // JBossMQProvider
1.1
jboss/src/main/org/jboss/jms/jndi/AbstractJMSProviderAdapter.java
Index: AbstractJMSProviderAdapter.java
===
/**
* JBoss, the OpenSource EJB server.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/asf OpenJMSServerSessionPoolFactory.java
User: user57 Date: 01/04/17 14:27:14 Removed: src/main/org/jboss/jms/asf OpenJMSServerSessionPoolFactory.java Log: o Removing files OpenJMS specific files that have been migrated to the contrib/openjms CVS module. o Added AbstractJMSProviderAdapter, which provides most of the bits that are required to implement a JMS provider. o Modified JBossMQProvider (and OpenJMSProvider in contrib/openjms) to extend AbstractJMSProviderAdapter. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
Maybe support the java:/ defaulting in 2.2.1 but issue a deprecation warning? Scott M Stark wrote: > > I don't have a strong opinion on its inclusion so if in general this is going to > cause more problems then it solves it can be left out of the 2.2.1 release. > An ApplicationMetaData level compatability flag could be added to indicate > whether the java:/ prefix should be assumed and this could be made true > by default in 2.2.1. I don't know that this should be mantained in the main > branch as using the full JNDI name that includes the java:/ prefix works and > that it could be left off is not documented anywhere that I can find. > > - Original Message - > From: "Jim Archer" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, April 17, 2001 1:49 PM > Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata >ApplicationMetaData.java > > > Can this change be postponed? Some of us are using code generators and it > > would be more than a simple search/replace exercise to accomadate this. > > > > Or, is it possible to set the code such that it works with or without the > > java: prefix? > > > > Jim > > > > --On Wednesday, April 18, 2001 8:14 AM +1200 Toby Allsopp > > <[EMAIL PROTECTED]> wrote: > > > > > On Tue, Apr 17, 2001 at 12:36:38PM -0700, [EMAIL PROTECTED] > > > wrote: > > >> User: starksm > > >> Date: 01/04/17 12:36:37 > > >> > > >> Modified:src/main/org/jboss/metadata Tag: Branch_2_2 > > >> ApplicationMetaData.java > > >> Log: > > >> Remove the requirement that the res-jndi-name be prefixed with java: > > > > > > This could break applications that used to work, right? Is this really a > > > "bug" that needs to be fixed for 2.2? > > > > > > I absolutely agree that it's a good idea in 2.3. If this is going into > > > 2.2, shouldn't the change note at least warn people that it might break > > > things? > > > > > > Toby. > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadataApplicationMetaData.java
That is correct. There will be no code changes required. Only certain undocumented usage of the jboss.xml descriptor res-jndi-name element will require changes to the res-jndi-name element. - Original Message - From: "danch" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 17, 2001 2:10 PM Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/metadataApplicationMetaData.java > Your code itself shouldn't change. I believe that it will just be places > where you're mapping resource references in jboss.xml that would change, > or have I misinterpreted, Scott? > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-416846 ] OpenJMS support migrated to contrib
Change Notes item #416846, was updated on 2001-04-17 14:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416846&group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Jason Dillon (user57) Assigned to: Nobody/Anonymous (nobody) Summary: OpenJMS support migrated to contrib Initial Comment: Support for OpenJMS as a JMS provider inside of JBoss has moved to an external contrib module: contrib/openjms The support classes have been repackaged into a single package in the contrib module, so users will need to update there configurations with the new package names: org.jboss.jms.openjms.OpenJMSProvider org.jboss.jms.openjms.OpenJMSServerSessionPoolFactory -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416846&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ApplicationMetaData issue and proposed 2.2.1 patch integration
There seems to be a bit of confusion as to exactly what the ApplicationMetaData
change that I committed is and what its impact will be. I'll describe the current
problem and then suggest an integration of the patch into the 2.2.1 release that
won't break any code or jboss.xml descriptors but will allow one to work
around the current problem if desired.
The current problem is that resources that are bound under a context
other than java:/ cannot be accessed from the standard ENC namespace.
For example, here are standard ENC names for accessing a javax.sql.DataSource,
a javax.mail.Session, and a javax.jms.QueueConnectionFactory:
Context env = new InitialContext();
javax.sql.DataSource ds = (javax.sql.DataSource)
env.lookup("java:comp/env/jdbc/DefaultDS");
javax.mail.Session s = (javax.mail.Session)
env.lookup("java:comp/env/mail/DefaultSession");
javax.jms.QueueConnectionFactory:qcf = (javax.jms.QueueConnectionFactory:)
env.lookup("java:comp/env/jms/DefaultQueueFactory");
As it stands now in 2.2, a mapping from the ENC name used by a developer to the
deployed
resource JNDI name can only be made if the deployed resource is located under the
java:/ context in the JBoss JNDI namespace. This is the default for some resources,
but the JMS resources managed by the JBossMQ module don't happen to use this
convention.
The restriction that a resource must be deployed under the java:/ context is hard coded
into the ApplicationMetaData and this does not allow a deployer to create a mapping
from a developer's "java:comp/env/jms/DefaultQueueFactory" name to the
"QueueConnectionFactory" name under which JBossMQ binds its
javax.jms.QueueConnectionFactory:
There is no reason why resources must be bound under the java:/ context and so the
hard coded check has been removed from the org.jboss.metadata.ApplicationMetaData
class.
Under no circumstances can this change require a change to the JNDI name used
to lookup a resource. The JNDI name used by a developer must either be
the ENC style name or the deployed JNDI name of the resource.
This change will break a jboss.xml deployment descriptor that is relying on a
java:/ prefix to be added to a res-jndi-name when the prefix is not specified.
For example, under 2.2 this jboss.xml fragment:
DefaultDS
DefaultDS
is really treated as:
DefaultDS
java:/DefaultDS
With the change to ApplicationMetaData the res-jndi-name value is no longer
forced to be relative to java:/ and so the first form will now fail.
I would like to make it possible to access any resource using the suggested ENC
naming convention in the 2.2.1 release, but since its not clear how many people
are using broken jboss.xml descriptors I'm proposing the following change.
The ApplicationMetaData will look for a
org.jboss.metadata.ApplicationMetaData.assumeJavaPrefix
property that will indicate whether the old behavior of assuming that all res-jndi-name
values that do not begin with a java:/ prefix should. The default value for this
property
will be true so that the current 2.2 behavior is the default. Anytime a res-jndi-name
seen that is not prefixed with java:/ when the property is true a warning msg will
be logged. If you don't want the 2.2 behavior you can set the assumeJavaPrefix
property to false on the command line or the jboss.properties file.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] DependencyManager & jboss.dependencies
It looks like log4j-old.jar (which contains classes in org.log4j) is not being referenced by any files in the jboss or contrib/log4j modules (except log4j-old.jar). So, it is *probably* safe to remove this file. --jason On Sun, 15 Apr 2001, Juha Lindfors wrote: > > Wanna take a look at the OpenJMS stuff too? :) > > It takes a meg in our package, and seems unnecessary as we use JBossMQ for > MDB. > The old log4j might be a good candidate for removal as well. > > -- Juha > > At 14:17 14.4.2001 -0700, you wrote: > >DependencyManager and jboss.dependencies have been removed. I also > >updated Main to remove the import of DependencyManager. I verified that > >the system builds correctly and runs with no other modifications too. > > > >--jason > > > >On Sat, 14 Apr 2001, marc fleury wrote: > > > >> |>From my investigation I would say that it is not being used anywhere > >> |inside of the jboss project. If this is true, it might be a good > >> |idea to at > >> |least remove the jboss.dependencies from the conf/default directory so > that > >> |it does not confuse anyone. > >> > >> correct, > >> > >> |I think that the DependencyManager is a good one, so I would not > >> |be so quick > >> |to suggest that it be removed. > >> > >> it was not a good one, remove it, we need to simplify simplify simplify > >> > >> marc > >> |http://lists.sourceforge.net/lists/listinfo/jboss-development > >> > >> > >> ___ > >> Jboss-development mailing list > >> [EMAIL PROTECTED] > >> http://lists.sourceforge.net/lists/listinfo/jboss-development > >> > > > > > >___ > >Jboss-development mailing list > >[EMAIL PROTECTED] > >http://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ApplicationMetaData issue and proposed 2.2.1 patchintegration
> I would like to make it possible to access any resource using the suggested ENC > naming convention in the 2.2.1 release, but since its not clear how many people > are using broken jboss.xml descriptors I'm proposing the following change. > The ApplicationMetaData will look for a >org.jboss.metadata.ApplicationMetaData.assumeJavaPrefix > property that will indicate whether the old behavior of assuming that all >res-jndi-name > values that do not begin with a java:/ prefix should. The default value for this >property > will be true so that the current 2.2 behavior is the default. Anytime a res-jndi-name > seen that is not prefixed with java:/ when the property is true a warning msg will > be logged. If you don't want the 2.2 behavior you can set the assumeJavaPrefix > property to false on the command line or the jboss.properties file. This sounds like a good idea. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/bin run.bat run.sh
User: starksm Date: 01/04/17 19:09:46 Modified:src/bin Tag: Branch_2_2 run.bat run.sh Log: Don't include the system CLASSPATH as this results in too many conflicts in general. Change CLASSPATH to JBOSS_CLASSPATH to make it clear that the CLASSPATH variable is not used. Revision ChangesPath No revision No revision 1.20.2.1 +5 -5 jboss/src/bin/run.bat Index: run.bat === RCS file: /cvsroot/jboss/jboss/src/bin/run.bat,v retrieving revision 1.20 retrieving revision 1.20.2.1 diff -u -r1.20 -r1.20.2.1 --- run.bat 2001/03/23 09:58:54 1.20 +++ run.bat 2001/04/18 02:09:46 1.20.2.1 @@ -2,19 +2,19 @@ @if not "%ECHO%" == "" echo %ECHO% @if "%OS%" == "Windows_NT" setlocal -set CLASSPATH=%CLASSPATH%;run.jar +set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;run.jar REM Add all login modules for JAAS-based security REM and all libraries that are used by them here -set CLASSPATH=%CLASSPATH% +set JBOSS_CLASSPATH=%JBOSS_CLASSPATH% REM Add the XML parser jars and set the JAXP factory names REM Crimson parser JAXP setup(default) -set CLASSPATH=%CLASSPATH%;../lib/crimson.jar +set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;../lib/crimson.jar set JAXP=-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl set JAXP=%JAXP% -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl -echo CLASSPATH=%CLASSPATH% -java %JAXP% -classpath "%CLASSPATH%" org.jboss.Main %1 %2 %3 %4 %5 %6 %7 %8 %9 +echo JBOSS_CLASSPATH=%JBOSS_CLASSPATH% +java %JAXP% -classpath "%JBOSS_CLASSPATH%" org.jboss.Main %1 %2 %3 %4 %5 %6 %7 %8 %9 pause 1.17.2.1 +5 -5 jboss/src/bin/run.sh Index: run.sh === RCS file: /cvsroot/jboss/jboss/src/bin/run.sh,v retrieving revision 1.17 retrieving revision 1.17.2.1 diff -u -r1.17 -r1.17.2.1 --- run.sh2001/03/23 09:58:54 1.17 +++ run.sh2001/04/18 02:09:46 1.17.2.1 @@ -2,18 +2,18 @@ # Minimal jar file to get JBoss started. -CLASSPATH=$CLASSPATH:run.jar +JBOSS_CLASSPATH=$JBOSS_CLASSPATH:run.jar # Add all login modules for JAAS-based security # and all libraries that are used by them here -CLASSPATH=$CLASSPATH +JBOSS_CLASSPATH=$JBOSS_CLASSPATH # Add the XML parser jars and set the JAXP factory names # Crimson parser JAXP setup(default) -CLASSPATH=$CLASSPATH:../lib/crimson.jar +JBOSS_CLASSPATH=$JBOSS_CLASSPATH:../lib/crimson.jar JAXP=-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl JAXP="$JAXP -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl" -echo CLASSPATH=$CLASSPATH -java -server $JAXP -classpath $CLASSPATH org.jboss.Main $@ +echo JBOSS_CLASSPATH=$JBOSS_CLASSPATH +java -server $JAXP -classpath $JBOSS_CLASSPATH org.jboss.Main $@ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-416920 ] Don't use CLASSPATH in run.bat/run.sh
Change Notes item #416920, was updated on 2001-04-17 19:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416920&group_id=22866 Category: None Group: v2.2.1 Status: Open Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Don't use CLASSPATH in run.bat/run.sh Initial Comment: Removed the use of the system CLASSPATH variable as this results in too many conflicts in general. Changed CLASSPATH to JBOSS_CLASSPATH to make it clear that the CLASSPATH variable is not used. If you are relying on the system CLASSPATH to include required jars you either need to edit run.bat/run.sh to include CLASSPATH or setup a JBOSS_CLASSPATH variable with the required jars. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416920&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/bin run.bat run.sh
User: starksm Date: 01/04/17 19:21:10 Modified:src/bin run.bat run.sh Log: Don't include the system CLASSPATH as this results in too many conflicts in general. Change CLASSPATH to JBOSS_CLASSPATH to make it clear that the CLASSPATH variable is not used. Revision ChangesPath 1.21 +5 -5 jboss/src/bin/run.bat Index: run.bat === RCS file: /cvsroot/jboss/jboss/src/bin/run.bat,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- run.bat 2001/03/23 09:58:54 1.20 +++ run.bat 2001/04/18 02:21:10 1.21 @@ -2,19 +2,19 @@ @if not "%ECHO%" == "" echo %ECHO% @if "%OS%" == "Windows_NT" setlocal -set CLASSPATH=%CLASSPATH%;run.jar +set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;run.jar REM Add all login modules for JAAS-based security REM and all libraries that are used by them here -set CLASSPATH=%CLASSPATH% +set JBOSS_CLASSPATH=%JBOSS_CLASSPATH% REM Add the XML parser jars and set the JAXP factory names REM Crimson parser JAXP setup(default) -set CLASSPATH=%CLASSPATH%;../lib/crimson.jar +set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;../lib/crimson.jar set JAXP=-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl set JAXP=%JAXP% -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl -echo CLASSPATH=%CLASSPATH% -java %JAXP% -classpath "%CLASSPATH%" org.jboss.Main %1 %2 %3 %4 %5 %6 %7 %8 %9 +echo JBOSS_CLASSPATH=%JBOSS_CLASSPATH% +java %JAXP% -classpath "%JBOSS_CLASSPATH%" org.jboss.Main %1 %2 %3 %4 %5 %6 %7 %8 %9 pause 1.18 +5 -5 jboss/src/bin/run.sh Index: run.sh === RCS file: /cvsroot/jboss/jboss/src/bin/run.sh,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- run.sh2001/03/23 09:58:54 1.17 +++ run.sh2001/04/18 02:21:10 1.18 @@ -2,18 +2,18 @@ # Minimal jar file to get JBoss started. -CLASSPATH=$CLASSPATH:run.jar +JBOSS_CLASSPATH=$JBOSS_CLASSPATH:run.jar # Add all login modules for JAAS-based security # and all libraries that are used by them here -CLASSPATH=$CLASSPATH +JBOSS_CLASSPATH=$JBOSS_CLASSPATH # Add the XML parser jars and set the JAXP factory names # Crimson parser JAXP setup(default) -CLASSPATH=$CLASSPATH:../lib/crimson.jar +JBOSS_CLASSPATH=$JBOSS_CLASSPATH:../lib/crimson.jar JAXP=-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl JAXP="$JAXP -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl" -echo CLASSPATH=$CLASSPATH -java -server $JAXP -classpath $CLASSPATH org.jboss.Main $@ +echo JBOSS_CLASSPATH=$JBOSS_CLASSPATH +java -server $JAXP -classpath $JBOSS_CLASSPATH org.jboss.Main $@ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-416922 ] on't use CLASSPATH in run.bat/run.sh
Change Notes item #416922, was updated on 2001-04-17 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416922&group_id=22866 Category: None Group: v2.4 Status: Open Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: on't use CLASSPATH in run.bat/run.sh Initial Comment: Removed the use of the system CLASSPATH variable as this results in too many conflicts in general. Changed CLASSPATH to JBOSS_CLASSPATH to make it clear that the CLASSPATH variable is not used. If you are relying on the system CLASSPATH to include required jars you either need to edit run.bat/run.sh to include CLASSPATH or setup a JBOSS_CLASSPATH variable with the required jars. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416922&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/etc/conf - New directory
User: starksm Date: 01/04/17 19:39:21 contrib/tomcat/src/etc/conf - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/etc - New directory
User: starksm Date: 01/04/17 19:39:09 contrib/tomcat/src/etc - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/etc/conf/tomcat - New directory
User: starksm Date: 01/04/17 19:39:35 contrib/tomcat/src/etc/conf/tomcat - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/etc/conf/tomcat jboss.conf.patch jboss.jcml.patch server.xml.patch
User: starksm Date: 01/04/17 19:40:41 Added: tomcat/src/etc/conf/tomcat jboss.conf.patch jboss.jcml.patch server.xml.patch Log: Patch files that transform the default dist config files into those required for the JBoss/EmbededTomcat bundle Revision ChangesPath 1.1 contrib/tomcat/src/etc/conf/tomcat/jboss.conf.patch Index: jboss.conf.patch === *** ../default/jboss.conf Tue Apr 17 13:28:07 2001 --- jboss.confTue Apr 17 13:30:03 2001 *** *** 41,52 ! ! ! ! ! - - - - - - + + + + + ! ! ! ! ! ! ! + - - - -
[JBoss-dev] CVS update: contrib/tomcat README
User: starksm Date: 01/04/17 19:43:21 Modified:tomcat README Log: Update the Ant build file to support building the JBoss/Tomcat prepackaged bundle given jboss.dist and tomcat.dist locations. Revision ChangesPath 1.3 +19 -16contrib/tomcat/README Index: README === RCS file: /cvsroot/jboss/contrib/tomcat/README,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- README2001/02/10 06:04:27 1.2 +++ README2001/04/18 02:43:21 1.3 @@ -1,11 +1,10 @@ contrib/tomcat module: -This module allows fast in VM integration of tomcat in jboss. +This module allows fast in VM integration of tomcat3.2.1 in jboss. - Requirements: - - jboss pre-2.1 - - tomcat 3.2 beta 4 + - jboss 2.2+ distribution + - tomcat 3.2.1 Compiling: @@ -15,23 +14,27 @@ - set the TOMCAT_HOME environment variable to the home of tomcat. If you use a CVS version, build tomcat first, and set the variable to $JAKARTA_HOME/dist/tomcat - + +Either: - go to the src/build directory, and do a build install. This will create a tomcat-service.jar file and copy it to $JBOSS_HOME/lib/ext - +Or: + - go to the src/build directory, and do a build bundle. This will create +a jboss-tomcat bundle directory that includes tomcat and jboss subdirs +which contain patched versions of the jboss and tomcat distributions. +The jboss subdir will contain a conf/tomcat directory with config +files configured to run the EmbededTomcat service. The tomcat subdir +will contain a patched conf/server.xml file that includes the interceptors +required for JBoss. Running jboss with tomcat: - - set the TOMCAT_HOME environment variable. - - edit jboss.conf to allow the EmbeddedTomcat service and to tell the j2eedeployer -to use tomcat as a wardeployer - - run jboss - - + - Execute the run.bat or run.sh passing in 'tomcat' as the sole argument. + Test client: -This client is a simple servlet that calls a simple session bean. To build the client, do a 'build client' in the src/build directory. +This client is a simple servlet that calls a simple session bean. To build +the client, do a 'build client' in the src/build directory. -To deploy the client, run jboss with the EmbededTomcat enabled, -copy tomcat-test.ear to your $JBOSS_HOME/deploy directory +To deploy the client, copy tomcat-test.ear to your $JBOSS_HOME/deploy directory +To run the client, surf to http://server:8080/jboss -To call the client, surf to http://server:8080/jboss ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/build build.xml
User: starksm
Date: 01/04/17 19:43:21
Modified:tomcat/src/build build.xml
Log:
Update the Ant build file to support building the JBoss/Tomcat prepackaged
bundle given jboss.dist and tomcat.dist locations.
Revision ChangesPath
1.9 +77 -39contrib/tomcat/src/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/tomcat/src/build/build.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- build.xml 2001/03/15 06:35:56 1.8
+++ build.xml 2001/04/18 02:43:21 1.9
@@ -1,35 +1,47 @@
-
-
+
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -62,31 +74,49 @@
-
-
+
-
-
-
+
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -114,9 +144,17 @@
basedir="${build.classes.dir}"
includes="org/jboss/test/tomcat/ejb/interfaces/**"
/>
-
+
+
+
+
+
+
+
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-416928 ] Removed res-jndi-name java:/ prefix need
Change Notes item #416928, was updated on 2001-04-17 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416928&group_id=22866 Category: None Group: v2.4 Status: Open Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Removed res-jndi-name java:/ prefix need Initial Comment: Fixed bug #414854. The requirement that the res-jndi-name be prefixed with java: has been removed from the ApplicationMetaData class. This change requires that a jboss.xml descriptor like: ENCBean DefaultDS jdbc/DefaultDS DefaultDS DefaultDS would now require a resource-managers element like: DefaultDS java:/DefaultDS where the res-jndi-name element value now must explicitly include the java:/ value that was assumed. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=416928&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/build build.bat build.sh build.xml
User: starksm Date: 01/04/17 20:18:08 Modified:tomcat/src/build build.bat build.sh build.xml Log: Change jboss.home & tomcat.home to jboss.dist & tomcat.dist Add fixcrlf task for the *.bat files Revision ChangesPath 1.4 +1 -1 contrib/tomcat/src/build/build.bat Index: build.bat === RCS file: /cvsroot/jboss/contrib/tomcat/src/build/build.bat,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- build.bat 2001/03/25 09:30:48 1.3 +++ build.bat 2001/04/18 03:18:08 1.4 @@ -18,4 +18,4 @@ set CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\crimson.jar set CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\jaxp.jar -java -Dtomcat.home=%TOMCAT_HOME% -Djboss.home=%JBOSS_HOME% -classpath "%CLASSPATH%" org.apache.tools.ant.Main %1 %2 %3 %4 %5 +java -Dtomcat.dist=%TOMCAT_HOME% -Djboss.dist=%JBOSS_HOME% -classpath "%CLASSPATH%" org.apache.tools.ant.Main %1 %2 %3 %4 %5 1.6 +1 -1 contrib/tomcat/src/build/build.sh Index: build.sh === RCS file: /cvsroot/jboss/contrib/tomcat/src/build/build.sh,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.sh 2001/03/25 09:30:48 1.5 +++ build.sh 2001/04/18 03:18:08 1.6 @@ -18,5 +18,5 @@ CLASSPATH=$CLASSPATH:$JBOSS_HOME/lib/crimson.jar CLASSPATH=$CLASSPATH:$JBOSS_HOME/lib/jaxp.jar -java -Dtomcat.home="$TOMCAT_HOME" -Djboss.home="$JBOSS_HOME" -classpath "$CLASSPATH" org.apache.tools.ant.Main $* +java -Dtomcat.dist="$TOMCAT_HOME" -Djboss.dist="$JBOSS_HOME" -classpath "$CLASSPATH" org.apache.tools.ant.Main $* 1.10 +9 -1 contrib/tomcat/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/tomcat/src/build/build.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- build.xml 2001/04/18 02:43:21 1.9 +++ build.xml 2001/04/18 03:18:08 1.10 @@ -1,5 +1,5 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/etc/conf/tomcat server.xml.patch
User: starksm Date: 01/04/17 21:30:51 Modified:tomcat/src/etc/conf/tomcat server.xml.patch Log: Change JBOSS_HOME to JBOSS_DIST Change TOMCAT_HOME to TOMCAT_DIST Update server.xml.patch to be against the shipped 3.2.1 server.xml file Revision ChangesPath 1.2 +22 -118 contrib/tomcat/src/etc/conf/tomcat/server.xml.patch Index: server.xml.patch === RCS file: /cvsroot/jboss/contrib/tomcat/src/etc/conf/tomcat/server.xml.patch,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- server.xml.patch 2001/04/18 02:40:41 1.1 +++ server.xml.patch 2001/04/18 04:30:51 1.2 @@ -1,22 +1,11 @@ -*** server.xml Tue Mar 13 13:15:37 2001 +*** server.xml Tue Dec 12 13:36:20 2000 --- server.jboss.xml Mon Apr 16 19:23:01 2001 *** -*** 123,153 - className="org.apache.tomcat.context.DefaultCMSetter" /> +*** 124,135 -! - -- -- - - -- +! -- -- - - - - -+ -+ -+ -+ - +! +! +! +! +! +! +! +! +! - - -! -! -! -! -! -! -! -+ - - - - - -- -- -- -- - - - ++ +
[JBoss-dev] CVS update: contrib/tomcat/src/build build.bat build.sh
User: starksm
Date: 01/04/17 21:30:51
Modified:tomcat/src/build build.bat build.sh
Log:
Change JBOSS_HOME to JBOSS_DIST
Change TOMCAT_HOME to TOMCAT_DIST
Update server.xml.patch to be against the shipped 3.2.1 server.xml file
Revision ChangesPath
1.5 +9 -9 contrib/tomcat/src/build/build.bat
Index: build.bat
===
RCS file: /cvsroot/jboss/contrib/tomcat/src/build/build.bat,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- build.bat 2001/04/18 03:18:08 1.4
+++ build.bat 2001/04/18 04:30:51 1.5
@@ -1,21 +1,21 @@
@echo off
REM convenience bat file to build with
-if not exist %TOMCAT_HOME%\lib\webserver.jar (
- echo %TOMCAT_HOME%\lib\webserver.jar does not exist
- echo set TOMCAT_HOME to the tomcat dist directory
+if not exist %TOMCAT_DIST%\lib\webserver.jar (
+ echo %TOMCAT_DIST%\lib\webserver.jar does not exist
+ echo set TOMCAT_DIST to the tomcat dist directory
exit
)
-if not exist %JBOSS_HOME%\bin\run.jar (
- echo %JBOSS_HOME%\bin\run.jar does not exist
- echo set JBOSS_HOME to the jboss dist directory
+if not exist %JBOSS_DIST%\bin\run.jar (
+ echo %JBOSS_DIST%\bin\run.jar does not exist
+ echo set JBOSS_DIST to the jboss dist directory
exit
)
set CLASSPATH=..\..\lib\ant.jar
set CLASSPATH=%CLASSPATH%;..\..\build\classes
set CLASSPATH=%CLASSPATH%;..\..\lib\javac.jar
-set CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\crimson.jar
-set CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\jaxp.jar
+set CLASSPATH=%CLASSPATH%;%JBOSS_DIST%\lib\crimson.jar
+set CLASSPATH=%CLASSPATH%;%JBOSS_DIST%\lib\jaxp.jar
-java -Dtomcat.dist=%TOMCAT_HOME% -Djboss.dist=%JBOSS_HOME% -classpath "%CLASSPATH%"
org.apache.tools.ant.Main %1 %2 %3 %4 %5
+java -Dtomcat.dist=%TOMCAT_DIST% -Djboss.dist=%JBOSS_DIST% -classpath "%CLASSPATH%"
org.apache.tools.ant.Main %1 %2 %3 %4 %5
1.7 +9 -9 contrib/tomcat/src/build/build.sh
Index: build.sh
===
RCS file: /cvsroot/jboss/contrib/tomcat/src/build/build.sh,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- build.sh 2001/04/18 03:18:08 1.6
+++ build.sh 2001/04/18 04:30:51 1.7
@@ -1,22 +1,22 @@
#!/bin/sh
-if [ ! -f "${JBOSS_HOME}/bin/run.jar" ]
+if [ ! -f "${JBOSS_DIST}/bin/run.jar" ]
then
- echo $JBOSS_HOME/bin/run.jar does not exist
- echo set JBOSS_HOME to the jboss dist directory
+ echo $JBOSS_DIST/bin/run.jar does not exist
+ echo set JBOSS_DIST to the jboss dist directory
exit 1
fi
-if [ ! -f "$TOMCAT_HOME/lib/webserver.jar" ]
+if [ ! -f "$TOMCAT_DIST/lib/webserver.jar" ]
then
- echo $TOMCAT_HOME/lib/webserver.jar does not exist
- echo set TOMCAT_HOME to the tomcat dist directory
+ echo $TOMCAT_DIST/lib/webserver.jar does not exist
+ echo set TOMCAT_DIST to the tomcat dist directory
exit 1
fi
CLASSPATH=../../lib/ant.jar
CLASSPATH=$CLASSPATH:../../build/classes
CLASSPATH=$CLASSPATH:../../lib/javac.jar
-CLASSPATH=$CLASSPATH:$JBOSS_HOME/lib/crimson.jar
-CLASSPATH=$CLASSPATH:$JBOSS_HOME/lib/jaxp.jar
+CLASSPATH=$CLASSPATH:$JBOSS_DIST/lib/crimson.jar
+CLASSPATH=$CLASSPATH:$JBOSS_DIST/lib/jaxp.jar
-java -Dtomcat.dist="$TOMCAT_HOME" -Djboss.dist="$JBOSS_HOME" -classpath
"$CLASSPATH" org.apache.tools.ant.Main $*
+java -Dtomcat.dist="$TOMCAT_DIST" -Djboss.dist="$JBOSS_DIST" -classpath
"$CLASSPATH" org.apache.tools.ant.Main $*
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat README
User: starksm Date: 01/04/17 21:30:51 Modified:tomcat README Log: Change JBOSS_HOME to JBOSS_DIST Change TOMCAT_HOME to TOMCAT_DIST Update server.xml.patch to be against the shipped 3.2.1 server.xml file Revision ChangesPath 1.4 +5 -5 contrib/tomcat/README Index: README === RCS file: /cvsroot/jboss/contrib/tomcat/README,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- README2001/04/18 02:43:21 1.3 +++ README2001/04/18 04:30:51 1.4 @@ -8,16 +8,16 @@ Compiling: - - set the JBOSS_HOME environment variable to the home of jboss. If you use a + - set the JBOSS_DIST environment variable to the home of jboss. If you use a CVS version of jboss, build jboss first and set it to jboss/dist - - set the TOMCAT_HOME environment variable to the home of tomcat. If you use + - set the TOMCAT_DIST environment variable to the home of tomcat. If you use a CVS version, build tomcat first, and set the variable to -$JAKARTA_HOME/dist/tomcat +$JAKARTA_DIST/dist/tomcat Either: - go to the src/build directory, and do a build install. This will create a -tomcat-service.jar file and copy it to $JBOSS_HOME/lib/ext +tomcat-service.jar file and copy it to $JBOSS_DIST/lib/ext Or: - go to the src/build directory, and do a build bundle. This will create a jboss-tomcat bundle directory that includes tomcat and jboss subdirs @@ -35,6 +35,6 @@ This client is a simple servlet that calls a simple session bean. To build the client, do a 'build client' in the src/build directory. -To deploy the client, copy tomcat-test.ear to your $JBOSS_HOME/deploy directory +To deploy the client, copy tomcat-test.ear to your $JBOSS_DIST/deploy directory To run the client, surf to http://server:8080/jboss ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/metadata ApplicationMetaData.java
User: starksm
Date: 01/04/17 23:04:28
Modified:src/main/org/jboss/metadata Tag: Branch_2_2
ApplicationMetaData.java
Log:
Add a org.jboss.metadata.ApplicationMetaData.assumeJavaPrefix property that
defaults to true which restores the 2.2 behavior requiring all res-jndi-name
value to begin with java:/
Revision ChangesPath
No revision
No revision
1.13.2.2 +16 -2 jboss/src/main/org/jboss/metadata/ApplicationMetaData.java
Index: ApplicationMetaData.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/metadata/ApplicationMetaData.java,v
retrieving revision 1.13.2.1
retrieving revision 1.13.2.2
diff -u -r1.13.2.1 -r1.13.2.2
--- ApplicationMetaData.java 2001/04/17 19:36:37 1.13.2.1
+++ ApplicationMetaData.java 2001/04/18 06:04:28 1.13.2.2
@@ -18,8 +18,8 @@
import org.w3c.dom.NodeList;
import org.jboss.ejb.DeploymentException;
+import org.jboss.logging.Logger;
-
/**
*
*
@@ -27,7 +27,8 @@
* @see
* @author mailto:[EMAIL PROTECTED]">Sebastien Alborini
* @author Peter Antman ([EMAIL PROTECTED])
- * @version $Revision: 1.13.2.1 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.13.2.2 $
*/
public class ApplicationMetaData extends MetaData {
// Constants -
@@ -336,6 +337,19 @@
String url = getElementContent(getOptionalChild(resourceManager,
"res-url"));
+ // Check java:/ prefix behavior
+ String prop =
System.getProperty("org.jboss.metadata.ApplicationMetaData.assumeJavaPrefix", "true");
+ boolean assumeJavaPrefix = Boolean.valueOf(prop).booleanValue();
+ if( assumeJavaPrefix == true && jndi != null )
+ {
+ // Require that all value begin with java:/
+ if( jndi.startsWith("java:/") == false )
+ {
+ Logger.warning("res-jndi-name("+jndi+")does not start with
java:/ and assumeJavaPrefix is true");
+ jndi = "java:/" + jndi;
+ }
+ }
+
if (jndi != null && url == null) {
resources.put(resName, jndi);
} else if (jndi == null && url != null) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
