Re: [JBoss-dev] 1 to Many Relations
Dain Sundstrom wrote:
OK i'm playing with the latest RH CVS and testing out 1 to many
relations (bi directional). So ..
Table1 {
primary_key int,
}
TableMany {
primary_key int,
table1_key int,
}
class Table1 {
int getPrimary_key()
Collection getTableMany();
}
class TableMany {
int getPrimary_key();
int getTable1_key();
}
the problem is that when it tries to fetch TableMany it looks for a
field called table1_key_primary_key. It would seem that the
default key
should not be made up but the foreign key of the other side of the
relationship. So line 80 of JDBCRelationshipRoleMetaData.java should
just be
tempCmrFieldName = relatedRole.getEntityName();
1. Defaults can be overridden.
This is the default case. The strange cases should be overridden. Read
Marc's bit about packaging.
2. What happens when you have two one-to-many relationships between Table1
and TableMany?
Doesn't matter you still need Table1's primary key in TableMany. So you
would have
Table1 {
Collection getTableMany();
Collectiont getTableMany2();
}
TableMany {
int getTable1_key();
int getTable2_2_key();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/developers CVSAdmin.jsp
User: gropi Date: 01/11/16 03:43:33 Modified:src/docs/developers CVSAdmin.jsp Log: Align the numbering of the descriptions with the numbering of the points in the picture. Revision ChangesPath 1.3 +3 -4 newsite/src/docs/developers/CVSAdmin.jsp Index: CVSAdmin.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/developers/CVSAdmin.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- CVSAdmin.jsp 2001/10/12 23:01:28 1.2 +++ CVSAdmin.jsp 2001/11/16 11:43:33 1.3 @@ -60,13 +60,12 @@ p class=headEXAMPLE RELEASE SCENARIOS -p class=textConsider events 1-12 in blue on the following figure: +p class=textConsider events 1-13 in blue on the following figure: img src=/pictures/cvs_structure.png width=700 height=550 border=0 title=CVS Branch Structure alt=CVS Structure -ol start=0 -li +br Prior to event 1, the latest alpha development build is Rel_2_1_0_57. At this point it is decided to create a new binary release. -/li +ol start=0 li This is the creation of a 2.2 branch. It is labeled with a branch tag of Branch_2_2. This fixes the major version to 2 and the minor version to 2 for all tags on this branch. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: LONG: RE: [JBoss-dev] can't build jboss from cvs
|For JBoss.org, this is perfectly acceptable. However, for the |real upload to |Debian, this won't work, as I have said previously. Then you are shit out of luck kid, marcf | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
I think that all the extra information will confuse new JBoss users. If a
person is advanced enough to want to debug components within JBoss they
will be advanced enough to edit the log4j properties themselves.
-Phil
Jason Dillon [EMAIL PROTECTED]
Sent by: To:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
eforge.net cc:
Subject:
[JBoss-dev] suggest changing
log4j layout patterns
11/15/2001 05:09 PM
I suggest that we change the log4j layout patterns to add more useful
information to the console and server.log files:
For console:
%-5p %c{1} [%t] - %m%n
INFO JMXAdaptorService [main] - Starting
DEBUG MailingPOEJB [Passivator Thread for MailingPO] - ejbPassivate
For server.log:
%d %-5r %-5p %c [%t] (%x) - %m%n
2001-11-13 11:35:32,210 2396 INFO org.jboss.util.Shutdown [main] () -
Shutdown hook added
2001-11-13 11:35:36,576 6762 WARN
org.jboss.configuration.ConfigurationService [main] () -
Monitor:name=BeanCacheMonitor does not implement any Service methods
* * *
I have found that the extra information is very, very useful to debug
components running inside of JBoss. The above puts the minimal amount of
useful information on the console in a terse format and dumps all usefull
information into server.log in a verbose format.
I believe that users of JBoss would benifit from these settings by default
and I suggest that we update the log4j.properties (or use log4j.xml) with
these layout formats.
Any objections?
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 1 to Many Relations
Dain Sundstrom wrote:
OK i'm playing with the latest RH CVS and testing out 1 to many
relations (bi directional). So ..
Table1 {
primary_key int,
}
TableMany {
primary_key int,
table1_key int,
}
class Table1 {
int getPrimary_key()
Collection getTableMany();
}
class TableMany {
int getPrimary_key();
int getTable1_key();
}
the problem is that when it tries to fetch TableMany it looks for a
field called table1_key_primary_key. It would seem that the
default key
should not be made up but the foreign key of the other side of the
relationship. So line 80 of
JDBCRelationshipRoleMetaData.java should
just be
tempCmrFieldName = relatedRole.getEntityName();
1. Defaults can be overridden.
This is the default case. The strange cases should be
overridden. Read
Marc's bit about packaging.
What bit about packaging?
2. What happens when you have two one-to-many relationships
between Table1
and TableMany?
Doesn't matter you still need Table1's primary key in
TableMany. So you
would have
Table1 {
Collection getTableMany();
Collectiont getTableMany2();
}
TableMany {
int getTable1_key();
int getTable2_2_key();
}
You have lost me. What is the problem?
Let us clean up the example:
Musician {
String name; // pk
Collection getComposedSongs();
Collection getPreformedSongs();
}
CDTrack {
String uuid; // pk
Musician getComposer();
Musician getPerformer();
}
You would get the following table:
Musician {
name
}
CDTrack {
uuid,
musician_composer_name,
musician_performer_name
}
As you can see you get fk with the following pattern:
related_entity_name_cmr_field_name_related_entity_pk_field_name
unless the many side does not have a cmr field for the relationshiop then
you get:
related_entity_name_related_cmr_field_name_related_entity_pk_field_name
Or am I answering the wrong question?
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
On Fri, 16 Nov 2001 [EMAIL PROTECTED] wrote: I think that all the extra information will confuse new JBoss users. If a person is advanced enough to want to debug components within JBoss they will be advanced enough to edit the log4j properties themselves. On that note, it might be nice to list some suggested patterns that users could set log4j to use, as a convience. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 1 to Many Relations
I'm using xdoclet to generate the ejb-jar.xml file. When you are
generating the accessor methods it automaticly assumes that
the accessor
name matches the database column name. So in your example by
default it
is looking for a database columns named composer and performer.
This is a packaging issue, ie how much work and how confusing
is it to
generate the ejb-jar.xml files. From my point of view I think
that the
simplist case is that each database column has a matching
get/set method
. So in xdoclet ..
Musician {
String name; // pk
/**
@ejb:persist-field
@ejb:relation name=songs_composer
*/
Collection getComposedSongs();
}
CDTrack {
String uuid; // pk
/**
@ejb:persist-field
@ejb:relation name=songs_composer
*/
Musician getComposer();
}
Generates
ejb-relation
ejb-relation-namesongs_composer/ejb-relation-name
ejb-relationship-role
multiplicityMany/multiplicity
relationship-role-source
ejb-nameCDTrack/ejb-name
/relationship-role-source
cmr-field
cmr-field-namecomposer/cmr-field-name
/cmr-field
/ejb-relationship-role
ejb-relationship-role
multiplicityOne/multiplicity
relationship-role-source
ejb-nameMusician/ejb-name
/relationship-role-source
cmr-field
cmr-field-nameCDTrack/cmr-field-name
cmr-field-typejava.util.Collection/cmr-field-type
/cmr-field
/ejb-relationship-role
/ejb-relation
Tables ..
Musician {
String name;
}
CDTrack {
String uuid;
String composer;
}
Got it?
So what is the problem? Table mapping is an implementation detail. Does
the above not deploy? Is ejb-doclet generating bad ddl?
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
The console output should be short and simple. In any production
envrionment your likely to not even be using it so its just for quick looks
and I don't want excessive info displayed there. The default server.log
format can be more verbose. Its also trival to change these settings if
you know enough about log4j, so I would rather keep the defaults
simpler and let you change them for your specific need.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 4:09 PM
Subject: [JBoss-dev] suggest changing log4j layout patterns
I suggest that we change the log4j layout patterns to add more useful
information to the console and server.log files:
For console:
%-5p %c{1} [%t] - %m%n
INFO JMXAdaptorService [main] - Starting
DEBUG MailingPOEJB [Passivator Thread for MailingPO] - ejbPassivate
For server.log:
%d %-5r %-5p %c [%t] (%x) - %m%n
2001-11-13 11:35:32,210 2396 INFO org.jboss.util.Shutdown [main] () -
Shutdown hook added
2001-11-13 11:35:36,576 6762 WARN
org.jboss.configuration.ConfigurationService [main] () -
Monitor:name=BeanCacheMonitor does not implement any Service methods
* * *
I have found that the extra information is very, very useful to debug
components running inside of JBoss. The above puts the minimal amount of
useful information on the console in a terse format and dumps all usefull
information into server.log in a verbose format.
I believe that users of JBoss would benifit from these settings by default
and I suggest that we update the log4j.properties (or use log4j.xml) with
these layout formats.
Any objections?
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 1 to Many Relations
When it tries to load the CDTrack relation it generates the following
sql statement ..
select uuid from CDTrack where composer_composed_songs=?
should be ..
select uuid from CDTrack where composer=?
Dain Sundstrom wrote:
I'm using xdoclet to generate the ejb-jar.xml file. When you are
generating the accessor methods it automaticly assumes that
the accessor
name matches the database column name. So in your example by
default it
is looking for a database columns named composer and performer.
This is a packaging issue, ie how much work and how confusing
is it to
generate the ejb-jar.xml files. From my point of view I think
that the
simplist case is that each database column has a matching
get/set method
. So in xdoclet ..
Musician {
String name; // pk
/**
@ejb:persist-field
@ejb:relation name=songs_composer
*/
Collection getComposedSongs();
}
CDTrack {
String uuid; // pk
/**
@ejb:persist-field
@ejb:relation name=songs_composer
*/
Musician getComposer();
}
Generates
ejb-relation
ejb-relation-namesongs_composer/ejb-relation-name
ejb-relationship-role
multiplicityMany/multiplicity
relationship-role-source
ejb-nameCDTrack/ejb-name
/relationship-role-source
cmr-field
cmr-field-namecomposer/cmr-field-name
/cmr-field
/ejb-relationship-role
ejb-relationship-role
multiplicityOne/multiplicity
relationship-role-source
ejb-nameMusician/ejb-name
/relationship-role-source
cmr-field
cmr-field-nameCDTrack/cmr-field-name
cmr-field-typejava.util.Collection/cmr-field-type
/cmr-field
/ejb-relationship-role
/ejb-relation
Tables ..
Musician {
String name;
}
CDTrack {
String uuid;
String composer;
}
Got it?
So what is the problem? Table mapping is an implementation detail. Does
the above not deploy? Is ejb-doclet generating bad ddl?
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
How about at least adding the priority. I don't think that this info that
will dump to console with this format is excesive, perhaps you might not
want the thread name there.
Do you know if we are still forced to use log4j.properties (instead of
log4j.xml) due to the JBoss TRACE priority?
--jason
On Fri, 16 Nov 2001, Scott M Stark wrote:
The console output should be short and simple. In any production
envrionment your likely to not even be using it so its just for quick looks
and I don't want excessive info displayed there. The default server.log
format can be more verbose. Its also trival to change these settings if
you know enough about log4j, so I would rather keep the defaults
simpler and let you change them for your specific need.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 4:09 PM
Subject: [JBoss-dev] suggest changing log4j layout patterns
I suggest that we change the log4j layout patterns to add more useful
information to the console and server.log files:
For console:
%-5p %c{1} [%t] - %m%n
INFO JMXAdaptorService [main] - Starting
DEBUG MailingPOEJB [Passivator Thread for MailingPO] - ejbPassivate
For server.log:
%d %-5r %-5p %c [%t] (%x) - %m%n
2001-11-13 11:35:32,210 2396 INFO org.jboss.util.Shutdown [main] () -
Shutdown hook added
2001-11-13 11:35:36,576 6762 WARN
org.jboss.configuration.ConfigurationService [main] () -
Monitor:name=BeanCacheMonitor does not implement any Service methods
* * *
I have found that the extra information is very, very useful to debug
components running inside of JBoss. The above puts the minimal amount of
useful information on the console in a terse format and dumps all usefull
information into server.log in a verbose format.
I believe that users of JBoss would benifit from these settings by default
and I suggest that we update the log4j.properties (or use log4j.xml) with
these layout formats.
Any objections?
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
The priority is fine but the thread is not. As of log4j 1.1.3 the log4j.dtd
says is supports a priority class but I have not tried it.
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 16, 2001 10:45 AM
Subject: Re: [JBoss-dev] suggest changing log4j layout patterns
How about at least adding the priority. I don't think that this info that
will dump to console with this format is excesive, perhaps you might not
want the thread name there.
Do you know if we are still forced to use log4j.properties (instead of
log4j.xml) due to the JBoss TRACE priority?
--jason
On Fri, 16 Nov 2001, Scott M Stark wrote:
The console output should be short and simple. In any production
envrionment your likely to not even be using it so its just for quick
looks
and I don't want excessive info displayed there. The default server.log
format can be more verbose. Its also trival to change these settings if
you know enough about log4j, so I would rather keep the defaults
simpler and let you change them for your specific need.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 4:09 PM
Subject: [JBoss-dev] suggest changing log4j layout patterns
I suggest that we change the log4j layout patterns to add more useful
information to the console and server.log files:
For console:
%-5p %c{1} [%t] - %m%n
INFO JMXAdaptorService [main] - Starting
DEBUG MailingPOEJB [Passivator Thread for MailingPO] - ejbPassivate
For server.log:
%d %-5r %-5p %c [%t] (%x) - %m%n
2001-11-13 11:35:32,210 2396 INFO org.jboss.util.Shutdown [main]
() -
Shutdown hook added
2001-11-13 11:35:36,576 6762 WARN
org.jboss.configuration.ConfigurationService [main] () -
Monitor:name=BeanCacheMonitor does not implement any Service methods
* * *
I have found that the extra information is very, very useful to debug
components running inside of JBoss. The above puts the minimal amount
of
useful information on the console in a terse format and dumps all
usefull
information into server.log in a verbose format.
I believe that users of JBoss would benifit from these settings by
default
and I suggest that we update the log4j.properties (or use log4j.xml)
with
these layout formats.
Any objections?
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
Has there been any thought as to making the log4j component a configurable MBean like the rest of the system? It would be nice to be able to configure the logging properties via some administration interface on the fly via jmx. Right now it looks as if there is only a thin wrapper around starting log4j and pointing at its configuration file.
By the way, has any significant amount of work been done on an administration/monitoring utility? I'd be interested in working on something like this (or starting it if it hasn't been done already)
-jason
Scott M Stark [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/16/2001 01:25 PM
Please respond to Scott M Stark
To:[EMAIL PROTECTED]
cc:
Subject:Re: [JBoss-dev] suggest changing log4j layout patterns
The console output should be short and simple. In any production
envrionment your likely to not even be using it so its just for quick looks
and I don't want excessive info displayed there. The default server.log
format can be more verbose. Its also trival to change these settings if
you know enough about log4j, so I would rather keep the defaults
simpler and let you change them for your specific need.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Jason Dillon [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 15, 2001 4:09 PM
Subject: [JBoss-dev] suggest changing log4j layout patterns
I suggest that we change the log4j layout patterns to add more useful
information to the console and server.log files:
For console:
%-5p %c{1} [%t] - %m%n
INFO JMXAdaptorService [main] - Starting
DEBUG MailingPOEJB [Passivator Thread for MailingPO] - ejbPassivate
For server.log:
%d %-5r %-5p %c [%t] (%x) - %m%n
2001-11-13 11:35:32,210 2396 INFO org.jboss.util.Shutdown [main] () -
Shutdown hook added
2001-11-13 11:35:36,576 6762 WARN
org.jboss.configuration.ConfigurationService [main] () -
Monitor:name=BeanCacheMonitor does not implement any Service methods
* * *
I have found that the extra information is very, very useful to debug
components running inside of JBoss. The above puts the minimal amount of
useful information on the console in a terse format and dumps all usefull
information into server.log in a verbose format.
I believe that users of JBoss would benifit from these settings by default
and I suggest that we update the log4j.properties (or use log4j.xml) with
these layout formats.
Any objections?
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
[EMAIL PROTECTED] wrote: Has there been any thought as to making the log4j component a configurable MBean like the rest of the system? It would be nice to be able to configure the logging properties via some administration interface on the fly via jmx. Right now it looks as if there is only a thin wrapper around starting log4j and pointing at its configuration file. I've begun doing a simple log4j console in the WebWork project (sf.net/projects/webwork) which will allow you to see the categories and set debug levels and stuff like that, and also get log output. I'm not doing it as MBean's though, but as a WAR file. The app just hooks directly into log4j without going through JMX. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
From your webapp is it possible to save the configuration changes so that they take affect next time? I haven't looked to see if RH retains that functionality or not, but being able to automatically save the config in jboss-auto is pretty nice for long term maintenance. -jason Rickard Öberg [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/16/2001 01:56 PM To:Jboss-Development @ Lists . Sourceforge . Net [EMAIL PROTECTED] cc: Subject:Re: [JBoss-dev] suggest changing log4j layout patterns [EMAIL PROTECTED] wrote: Has there been any thought as to making the log4j component a configurable MBean like the rest of the system? It would be nice to be able to configure the logging properties via some administration interface on the fly via jmx. Right now it looks as if there is only a thin wrapper around starting log4j and pointing at its configuration file. I've begun doing a simple log4j console in the WebWork project (sf.net/projects/webwork) which will allow you to see the categories and set debug levels and stuff like that, and also get log output. I'm not doing it as MBean's though, but as a WAR file. The app just hooks directly into log4j without going through JMX. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
[EMAIL PROTECTED] wrote: From your webapp is it possible to save the configuration changes so that they take affect next time? I haven't looked to see if RH retains that functionality or not, but being able to automatically save the config in jboss-auto is pretty nice for long term maintenance. Haven't really come that far in the development, but yes, that is definitely one of the goals. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 1 to Many Relations
Ok stop for a second.
Do you have a jbosscmp-jdbc.xml file that specifies the relationship should
be mapped to a foreign key field named composer? If yes, then this is a bug.
If no, then this is a suggestion.
If it is a suggestion, say so, and I will consider it. My main goal when
creating column names it to always allow an ejb jar to deploy without
requiring a jbosscmp-jdbc.xml file. When explaining the suggestion explain
why you would not get a name collision.
-dain
-Original Message-
From: Dave Smith [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 16, 2001 12:22 PM
To: Dain Sundstrom
Cc: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] 1 to Many Relations
When it tries to load the CDTrack relation it generates the following
sql statement ..
select uuid from CDTrack where composer_composed_songs=?
should be ..
select uuid from CDTrack where composer=?
Dain Sundstrom wrote:
I'm using xdoclet to generate the ejb-jar.xml file. When you are
generating the accessor methods it automaticly assumes that
the accessor
name matches the database column name. So in your example by
default it
is looking for a database columns named composer and performer.
This is a packaging issue, ie how much work and how confusing
is it to
generate the ejb-jar.xml files. From my point of view I think
that the
simplist case is that each database column has a matching
get/set method
. So in xdoclet ..
Musician {
String name; // pk
/**
@ejb:persist-field
@ejb:relation name=songs_composer
*/
Collection getComposedSongs();
}
CDTrack {
String uuid; // pk
/**
@ejb:persist-field
@ejb:relation name=songs_composer
*/
Musician getComposer();
}
Generates
ejb-relation
ejb-relation-namesongs_composer/ejb-relation-name
ejb-relationship-role
multiplicityMany/multiplicity
relationship-role-source
ejb-nameCDTrack/ejb-name
/relationship-role-source
cmr-field
cmr-field-namecomposer/cmr-field-name
/cmr-field
/ejb-relationship-role
ejb-relationship-role
multiplicityOne/multiplicity
relationship-role-source
ejb-nameMusician/ejb-name
/relationship-role-source
cmr-field
cmr-field-nameCDTrack/cmr-field-name
cmr-field-typejava.util.Collection/cmr-field-type
/cmr-field
/ejb-relationship-role
/ejb-relation
Tables ..
Musician {
String name;
}
CDTrack {
String uuid;
String composer;
}
Got it?
So what is the problem? Table mapping is an implementation
detail. Does
the above not deploy? Is ejb-doclet generating bad ddl?
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: LONG: RE: [JBoss-dev] can't build jboss from cvs
yOn Fri, 16 Nov 2001, marc fleury wrote: |For JBoss.org, this is perfectly acceptable. However, for the |real upload to |Debian, this won't work, as I have said previously. Then you are shit out of luck kid, Huh? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
1) There is a setting in log4j to re-read properties at set intervall 2) thats is the way to go -since log4j is logging before the MBean server is started /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
on 1-11-16 22.50, Peter Fagerlund at [EMAIL PROTECTED] wrote: 1) There is a setting in log4j to re-read properties at set intervall 2) thats is the way to go -since log4j is logging before the MBean server is started Well not really :-) log4j is started as a MBean after the MB Server but should in an unwarped logic start ahead ... it boils down to -when using frameworks --use them ! ... log4j has a lot of options like letting a admin UI set and save the properties ... and re-reading them at runtime ... /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 1 to Many Relations
Finally, we are on the same page ..not even a blue moon ...
Yup this is a suggestion. I agree 100% we need to avoid using
jbosscmp-jdbc.xml.
Ulitmately at the database level for each table there has to be a unique
column name(s) that acts as a foreign key for the relation. It also
can only participate in 1 relation.
For a many to many relationship with a mapping table could be a problem
if the field name on both sides of the relationship were the same. But I
would see this as an exception not the rule.
For self joins you would have to do like you do in the EJBQL and prefix
the column with the table name. Not a bad idea for all relations so
select uuid from CDTrack where composer=?
would be
select c.uuid from CDTrack as c where c.composer=?
Dain Sundstrom wrote:
Ok stop for a second.
Do you have a jbosscmp-jdbc.xml file that specifies the relationship should
be mapped to a foreign key field named composer? If yes, then this is a bug.
If no, then this is a suggestion.
If it is a suggestion, say so, and I will consider it. My main goal when
creating column names it to always allow an ejb jar to deploy without
requiring a jbosscmp-jdbc.xml file. When explaining the suggestion explain
why you would not get a name collision.
-dain
-Original Message-
From: Dave Smith [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 16, 2001 12:22 PM
To: Dain Sundstrom
Cc: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] 1 to Many Relations
When it tries to load the CDTrack relation it generates the following
sql statement ..
select uuid from CDTrack where composer_composed_songs=?
should be ..
select uuid from CDTrack where composer=?
Dain Sundstrom wrote:
I'm using xdoclet to generate the ejb-jar.xml file. When you are
generating the accessor methods it automaticly assumes that
the accessor
name matches the database column name. So in your example by
default it
is looking for a database columns named composer and performer.
This is a packaging issue, ie how much work and how confusing
is it to
generate the ejb-jar.xml files. From my point of view I think
that the
simplist case is that each database column has a matching
get/set method
. So in xdoclet ..
Musician {
String name; // pk
/**
@ejb:persist-field
@ejb:relation name=songs_composer
*/
Collection getComposedSongs();
}
CDTrack {
String uuid; // pk
/**
@ejb:persist-field
@ejb:relation name=songs_composer
*/
Musician getComposer();
}
Generates
ejb-relation
ejb-relation-namesongs_composer/ejb-relation-name
ejb-relationship-role
multiplicityMany/multiplicity
relationship-role-source
ejb-nameCDTrack/ejb-name
/relationship-role-source
cmr-field
cmr-field-namecomposer/cmr-field-name
/cmr-field
/ejb-relationship-role
ejb-relationship-role
multiplicityOne/multiplicity
relationship-role-source
ejb-nameMusician/ejb-name
/relationship-role-source
cmr-field
cmr-field-nameCDTrack/cmr-field-name
cmr-field-typejava.util.Collection/cmr-field-type
/cmr-field
/ejb-relationship-role
/ejb-relation
Tables ..
Musician {
String name;
}
CDTrack {
String uuid;
String composer;
}
Got it?
So what is the problem? Table mapping is an implementation
detail. Does
the above not deploy? Is ejb-doclet generating bad ddl?
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: LONG: RE: [JBoss-dev] can't build jboss from cvs
| |For JBoss.org, this is perfectly acceptable. However, for the | |real upload to | |Debian, this won't work, as I have said previously. | | Then you are shit out of luck kid, | |Huh? Debian's reasons for not allowing free/non-free software in their distros ranks about 0.002 on my scale of priorities (0-10). Really not my battle. There is and there will be non-free software in there, we need it. And I am not about to invest a second of work to accomodate your students ideals. You guys go wank in a corner we are playing for real here. So if the current build doesn't work for you, I really don't care, you can stick your religiousness where the sun doesn't shine. Is this clearer? marcf | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] suggest changing log4j layout patterns
Yeah, right. What frameworks don't do well is automatically configure themselves for all the possible situations they end up being embedded in. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Peter Fagerlund [EMAIL PROTECTED] To: Jboss-Development @ Lists . Sourceforge . Net [EMAIL PROTECTED] Sent: Friday, November 16, 2001 2:06 PM Subject: Re: [JBoss-dev] suggest changing log4j layout patterns on 1-11-16 22.50, Peter Fagerlund at [EMAIL PROTECTED] wrote: 1) There is a setting in log4j to re-read properties at set intervall 2) thats is the way to go -since log4j is logging before the MBean server is started Well not really :-) log4j is started as a MBean after the MB Server but should in an unwarped logic start ahead ... it boils down to -when using frameworks --use them ! ... log4j has a lot of options like letting a admin UI set and save the properties ... and re-reading them at runtime ... /peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Deployment exception on Clustering
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Monday, November 12, 2001 10:22 PM To: Andreas Schaefer Cc: [EMAIL PROTECTED]; Bill Burke; David Jencks Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering This won't do any good. If all required beans are present, the order will be create configure call before start start call after start with no opportunity for anything else to happen. Might as well put everything in start. Unfortunately Hirams suggestion of after server is started doesn't make sense- you never know when the server is completely started, someone is always about to add one more mbean. The only way the cluster stuff ever worked was there was a more or less hidden concept of a deployment unit, with a more or less explicit order, which could be used to hide dependencies. This only works if the explicit dependencies are between mbeans needed for a deployment unit (the depends tag from David Maplesden) or between deployment units themselves (my original recursive sar deployment scheme). For everything I've tried so far, the mbean-ref method is simpler, clearer, and reduces the need for fake and implicit dependencies than either of the other two methods, or the ordering in deployment unit method. For instance, in the ConnectionFactoryLoader, there was a really fake dependency on the RARDeployer, the only use of which was to help the RARDeployer notify the ConnectionFactoryLoaders when it deployed a rar. By making the RARDeployment mbean, and having the ConnectionFactoryLoader refer to it, the extraneous reference is no longer needed, and the actual dependence is clearly exposed. I think there must be a hidden ordering dependency in the cluster file. Again, I have 2 phase initialization. It's kind of my fault that it's not clear what exactly this 2 phase initialization is. ClusterPartition should be delegating init(), start() and stop() to HAPartitionImpl instead of the initialization logic being divided between the 2 classes. The Cluster has to apperar before any of the services it manages, right?, so it can be called from the init. Why not make this dependency explicit? The more important question is, How can I get 2 phase initialization with the current MBean code base now that you've removed init(). Does your patch you gave me show how to do this? Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Deployment exception on Clustering
On 2001.11.16 17:33:17 -0500 Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Monday, November 12, 2001 10:22 PM To: Andreas Schaefer Cc: [EMAIL PROTECTED]; Bill Burke; David Jencks Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering snip The more important question is, How can I get 2 phase initialization with the current MBean code base now that you've removed init(). Does your patch you gave me show how to do this? I think so, I think the same code is executing in the same order as it used to be, for the HAJNDI. Used to be: ClusterPartition init HAJNDI init ClusterPartition start HAJNDI start Now, ClusterPartition has a reference to HAJNDI, so start wont be called on it until HAJNDI is started. What I did is like this (and may have a problem-- see below) HAJNDI start (empty method) ClusterPartition Start (does this, in terms of old methods: CP init (calls registerCluster on HAJNDI) which contains HAJNDI init HAJNDI start (!!!this might be a problem!!!) CP start If it is necessary to put the HAJNDI start last, you can make another method call from ClusterPartition to HAJNDI. Hope this is getting a little clearer;-) Please ask more if there is anything else I can do. david jencks Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 1 to Many Relations
You can set a different column name using @jboss:column-name (see
http://xdoclet.sourceforge.net/jboss.html#column-name)
cheers
dim
On Fri, 16 Nov 2001, Dave Smith wrote:
I'm using xdoclet to generate the ejb-jar.xml file. When you are
generating the accessor methods it automaticly assumes that the accessor
name matches the database column name. So in your example by default it
is looking for a database columns named composer and performer.
This is a packaging issue, ie how much work and how confusing is it to
generate the ejb-jar.xml files. From my point of view I think that the
simplist case is that each database column has a matching get/set method
. So in xdoclet ..
Musician {
String name; // pk
/**
@ejb:persist-field
@ejb:relation name=songs_composer
*/
Collection getComposedSongs();
}
CDTrack {
String uuid; // pk
/**
@ejb:persist-field
@ejb:relation name=songs_composer
*/
Musician getComposer();
}
Generates
ejb-relation
ejb-relation-namesongs_composer/ejb-relation-name
ejb-relationship-role
multiplicityMany/multiplicity
relationship-role-source
ejb-nameCDTrack/ejb-name
/relationship-role-source
cmr-field
cmr-field-namecomposer/cmr-field-name
/cmr-field
/ejb-relationship-role
ejb-relationship-role
multiplicityOne/multiplicity
relationship-role-source
ejb-nameMusician/ejb-name
/relationship-role-source
cmr-field
cmr-field-nameCDTrack/cmr-field-name
cmr-field-typejava.util.Collection/cmr-field-type
/cmr-field
/ejb-relationship-role
/ejb-relation
Tables ..
Musician {
String name;
}
CDTrack {
String uuid;
String composer;
}
Got it?
Dain Sundstrom wrote:
Dain Sundstrom wrote:
OK i'm playing with the latest RH CVS and testing out 1 to many
relations (bi directional). So ..
Table1 {
primary_key int,
}
TableMany {
primary_key int,
table1_key int,
}
class Table1 {
int getPrimary_key()
Collection getTableMany();
}
class TableMany {
int getPrimary_key();
int getTable1_key();
}
the problem is that when it tries to fetch TableMany it looks for a
field called table1_key_primary_key. It would seem that the
default key
should not be made up but the foreign key of the other side of the
relationship. So line 80 of
JDBCRelationshipRoleMetaData.java should
just be
tempCmrFieldName = relatedRole.getEntityName();
1. Defaults can be overridden.
This is the default case. The strange cases should be
overridden. Read
Marc's bit about packaging.
What bit about packaging?
2. What happens when you have two one-to-many relationships
between Table1
and TableMany?
Doesn't matter you still need Table1's primary key in
TableMany. So you
would have
Table1 {
Collection getTableMany();
Collectiont getTableMany2();
}
TableMany {
int getTable1_key();
int getTable2_2_key();
}
You have lost me. What is the problem?
Let us clean up the example:
Musician {
String name; // pk
Collection getComposedSongs();
Collection getPreformedSongs();
}
CDTrack {
String uuid; // pk
Musician getComposer();
Musician getPerformer();
}
You would get the following table:
Musician {
name
}
CDTrack {
uuid,
musician_composer_name,
musician_performer_name
}
As you can see you get fk with the following pattern:
related_entity_name_cmr_field_name_related_entity_pk_field_name
unless the many side does not have a cmr field for the relationshiop then
you get:
related_entity_name_related_cmr_field_name_related_entity_pk_field_name
Or am I answering the wrong question?
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 1 to Many Relations
ok - sorry... cheers dim On Fri, 16 Nov 2001, Dave Smith wrote: I know. The point is as far as I am concered this is the most basic of cases. We want to avoid users having to know jboss'isms unless they are doing something quite weird. Dmitri Colebatch wrote: You can set a different column name using @jboss:column-name (see http://xdoclet.sourceforge.net/jboss.html#column-name) cheers dim ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs designnotes.xml
User: luke_t Date: 01/11/16 17:27:26 Modified:src/xdocs designnotes.xml Log: addition of id attributes for reference from FAQ Revision ChangesPath 1.2 +2 -2 manual/src/xdocs/designnotes.xml Index: designnotes.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/designnotes.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- designnotes.xml 2001/08/29 09:19:36 1.1 +++ designnotes.xml 2001/11/17 01:27:26 1.2 @@ -1,5 +1,5 @@ ?xml version = 1.0 encoding = UTF-8? -chapter +chapter id=design titleContainer architecture - design notes/title paraAuthor:author firstnameVladimir/firstname @@ -234,7 +234,7 @@ server side. Consult RMI specification for more info./para /section /section - section + section id=design.jmx titleJMX - foundation of JBoss infrastructure/title section titleIntroduction/title ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs faq.xml
User: luke_t Date: 01/11/16 17:28:10 Modified:src/xdocs faq.xml Log: more basic knocking into shape Revision ChangesPath 1.2 +69 -51manual/src/xdocs/faq.xml Index: faq.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/faq.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- faq.xml 2001/11/15 22:03:59 1.1 +++ faq.xml 2001/11/17 01:28:10 1.2 @@ -1,15 +1,16 @@ ?xml version=1.0 encoding=UTF-8? -!-- !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN docbookx/docbookx.dtd -- +!-- DOCTYPE article SYSTEM ../../../ThirdParty/oasis/docbook-xml/docbookx.dtd -- + article class=faq articleinfo titleJBoss FAQ/title - releaseinfo$Revision: 1.1 $, $Date: 2001/11/15 22:03:59 $/releaseinfo + releaseinfo$Revision: 1.2 $, $Date: 2001/11/17 01:28:10 $/releaseinfo !--revhistory revision - revnumber$Revision: 1.1 $/revnumber - date$Date: 2001/11/15 22:03:59 $/date + revnumber$Revision: 1.2 $/revnumber + date$Date: 2001/11/17 01:28:10 $/date /revision /revhistory -- @@ -32,7 +33,7 @@ qandaentry id=faq.intro.version questionparaWhat is the version of this FAQ and when was it last updated?/para/question answer - paraThis is $Revision: 1.1 $ of the FAQ. The last update was made on $Date: 2001/11/15 22:03:59 $./para + paraThis is $Revision: 1.2 $ of the FAQ. The last update was made on $Date: 2001/11/17 01:28:10 $./para /answer /qandaentry @@ -41,12 +42,12 @@ answer paraEverybody :)./para paraTODO: list original creators and maintainers.../para -!-- -The first version of the JBoss FAQ was created by Kunle Odutola in March 2000. The second version of the FAQ was a rewrite by Jeremiah Johnson in August 2000 with maintenance by Kunle Odutola. The current version is maintained by Dewayne McNair. + !-- + The first version of the JBoss FAQ was created by Kunle Odutola in March 2000. The second version of the FAQ was a rewrite by Jeremiah Johnson in August 2000 with maintenance by Kunle Odutola. The current version is maintained by Dewayne McNair. -Most of the wisdom contained in the answers presented here however comes from the collective insights and diligence of the many others who inhabit the JBoss mailing list(s) and the EJB world-at-large. + Most of the wisdom contained in the answers presented here however comes from the collective insights and diligence of the many others who inhabit the JBoss mailing list(s) and the EJB world-at-large. --- + -- /answer /qandaentry @@ -70,26 +71,23 @@ The Java 2 Platform Enterprise Edition (J2EE) is the platform for developing, deploying and managing n-tiered information systems using Java technologies. The platform encourages the development of enterprise systems with the ability to run emphasisanywhere/emphasis across a wide range of operating systems. J2EE extends the Java 2 Platform to cater for the server-side processing needs of the enterprise with key technologies including the following: itemizedlist - !-- TODO: Add links to java.sun.com etc. here -- - listitemparaEnterprise JavaBeans (EJB)/para/listitem - - listitemparaJava Naming and Directory Interface (JNDI)/para/listitem + listitemparaEnterprise JavaBeans (ulink url=http://java.sun.com/products/ejb/index.html;EJB/ulink)/para/listitem - listitemparaJDBC data access API/para/listitem + listitemparaJava Naming and Directory Interface (ulink url=http://java.sun.com/products/jndi/index.html;JNDI/ulink)/para/listitem - listitemparaJava Servlets/para/listitem + listitemparaulink url=http://java.sun.com/products/jdbc/index.html;JDBC/ulink data access API/para/listitem - listitemparaJavaServer Pages (JSP)/para/listitem + listitemparaJava ulink url=http://java.sun.com/products/servlet/index.html;Servlets/ulink/para/listitem - listitemparaJava Transaction API (JTA)/para/listitem + listitemparaJavaServer Pages (ulink url=http://java.sun.com/products/jsp/index.html;JSP/ulink)/para/listitem - listitemparaJava Transaction Service (JTS)/para/listitem +
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 187 Successful tests: 148 Errors:25 Failures: 14 [time of test: 17 November 2001 3:59 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details 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 [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.xml
User: user57
Date: 01/11/16 20:13:58
Modified:jbossbuild.xml
Log:
o help should depend on init to get the correct module.Name
Revision ChangesPath
1.48 +3 -3 build/jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/build/jboss/build.xml,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- build.xml 2001/11/15 22:14:46 1.47
+++ build.xml 2001/11/17 04:13:58 1.48
@@ -10,7 +10,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.47 2001/11/15 22:14:46 user57 Exp $ --
+!-- $Id: build.xml,v 1.48 2001/11/17 04:13:58 user57 Exp $ --
project default=main name=JBoss/Build
@@ -139,7 +139,7 @@
!-- Module name(s) version --
property name=module.name value=jboss/
-property name=module.Name value=JBoss/
+property name=module.Name value=JBoss Build/
property name=module.version
value=${version.major}.${version.minor}.${version.revision}${version.tag}/
!-- Invoke the rest of the configuration targets --
@@ -1440,7 +1440,7 @@
!-- Help --
!-- == --
- target name=help
+ target name=help depends=init
projecthelp taskname=help
header![CDATA[
The ${module.Name} module.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/common picateam.jsp
User: user57 Date: 01/11/16 20:19:12 Modified:src/docs/common picateam.jsp Log: o cleaned up main.css, so it is more readable o touched up some problems with buildsystem.jsp o changed CVS module formatting, removed trailing ant fluff and re-formated the top of cvs.jsp o added a quick start guide o added a buildsystem faq (still needs more q to a) o added the quick start, build system and SF project info page to the developer navigation. * eventually want to replace these nav links to a single Guides page, which can list over all of them... but for now these are the big ones developers will want to see. o minor non-visual formatting changes to slogan and picateam Revision ChangesPath 1.3 +3 -10 newsite/src/docs/common/picateam.jsp Index: picateam.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/common/picateam.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- picateam.jsp 2001/11/08 19:06:21 1.2 +++ picateam.jsp 2001/11/17 04:19:12 1.3 @@ -76,14 +76,7 @@ java.util.Random random = new java.util.Random(); % - a class=link href=/team.jsp -img - align=left - border=1 - hspace=10 - vspace=3 - % int select = new Float(random.nextFloat()*people.length).intValue(); % - alt=%= names[select] % - src=/pictures/%= people[select] % -/a \ No newline at end of file + img align=left border=1 hspace=10 vspace=3 +% int select = new Float(random.nextFloat()*people.length).intValue(); % +alt=%= names[select] % src=/pictures/%= people[select] %/a ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/developers buildsystem-faq.jsp quickstart.jsp buildsystem.jsp cvs.jsp navigation.jsp slogan.jsp
User: user57 Date: 01/11/16 20:19:12 Modified:src/docs/developers buildsystem.jsp cvs.jsp navigation.jsp slogan.jsp Added: src/docs/developers buildsystem-faq.jsp quickstart.jsp Log: o cleaned up main.css, so it is more readable o touched up some problems with buildsystem.jsp o changed CVS module formatting, removed trailing ant fluff and re-formated the top of cvs.jsp o added a quick start guide o added a buildsystem faq (still needs more q to a) o added the quick start, build system and SF project info page to the developer navigation. * eventually want to replace these nav links to a single Guides page, which can list over all of them... but for now these are the big ones developers will want to see. o minor non-visual formatting changes to slogan and picateam Revision ChangesPath 1.2 +191 -101 newsite/src/docs/developers/buildsystem.jsp Index: buildsystem.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/developers/buildsystem.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- buildsystem.jsp 2001/11/16 02:14:00 1.1 +++ buildsystem.jsp 2001/11/17 04:19:12 1.2 @@ -1,23 +1,44 @@ jsp:include page=head.jsp flush=true/ +!-- $Id: buildsystem.jsp,v 1.2 2001/11/17 04:19:12 user57 Exp $ -- jsp:include page=slogan.jsp flush=true jsp:param name=SLOGAN value=BUILD SYSTEM GUIDE/ /jsp:include !-- -- +!-- Preface -- + +!-- picateam block --tabletrtdjsp:include page=/common/picateam.jsp flush=true//tdtd + +p class=text + This document is meant as a general guide to the JBoss build system. If + you are looking to get working with the sources right away you are better + off looking at the a href=quickstart.jspQuicknbsp;Startnbsp;Guide/a. + +p class=text + For a list of frequently asked questions (and their answers) check out + the a href=buildsystem-faq.jspBuildnbsp;Systemnbsp;FAQ/a. + +!-- end picateam block --/td/tr/table + +!-- -- + p class=heada name=ContentsContents/a - ul - lia class=link href=#OverviewOverview/a - lia class=link href=#Project_OverviewProject Overview/a - lia class=link href=#Module_OverviewModule Overview/a - lia class=link href=#The_build_ModuleThe embuild/em Module/a + +p class=text + ul class=text + lia href=#IntroductionIntroduction/a + lia href=#Project_OverviewProject Overview/a + lia href=#Module_OverviewModule Overview/a + lia href=#The_build_ModuleThe embuild/em Module/a /ul !-- -- -p class=heada name=OverviewOverviewa/ +p class=head + a name=IntroductionIntroductiona/ -p class=text +p class=texta name=About_Ant/a The JBoss build system is based on a href=http://jakarta.apache.org/ant;Ant/a from our friends at the a href=http://jakarta.apache.org;Apache Jakarta/a project. @@ -44,36 +65,40 @@ really need to execute a shell command, Ant has an exec rule that allows different commands to be executed based on the OS that it is executing on. +p class=text + a href=#Contents[Contents]/a + !-- -- -p class=heada name=Project_OverviewProject Overviewa/ +p class=head + a name=Project_OverviewProject Overviewa/ p class=text Each project contains a set of modules. Each project has at least a - embuild/em, emtools/em, emthirdparty/em, one or more emlocal - modules/em and zero or more emexternal modules/em. + ttbuild/tt, tttools/tt, ttthirdparty/tt, one or more + emlocal/em modules and zero or more emexternal/em modules. p class=text - emtools/em is a special module which contains the scripts and libraries + tttools/tt is a special module which contains the scripts and libraries required by the build system to run correctly. This inclues ant, buildmagic and other required ant libs. Its layout looks like this: - pre - bin/ - lib/ - /pre + blockquote + ttbin//ttbr + ttlib//ttbr + /blockquote p class=text This module is included in each project by the CVS module definition file (ttCVSROOT/modules/tt). In most cases the tools module for each - project is simply included from the tt/tools/tt CVS module. + project is simply included from the tttools/tt CVS module. p class=text - Even though there is a tttools/bin/tt directory, files in there are + Even though there is a tttools/bin//tt directory, files in there are not
[JBoss-dev] more build system docs
I just finished commiting a Quick Start Guide, the start of a Build System FAQ and some minor cosmetic changes to the CVS page. I also added the quick start and build system guides to the nav link as well as the SourceForge page for JBoss. I will eventually get around to adding a page to collect these new guides (as well as others to come), but I have had enough of documentation for today. This should be updated for viewing tomorrow, or in about 5 or 6 hours from now as the website updates. Let me know what other items that I can add to the Build System FAQ, if you can think of anything. Happy reading =) Now on to nntp... --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs main.css
User: user57
Date: 01/11/16 20:19:12
Modified:src/docs main.css
Log:
o cleaned up main.css, so it is more readable
o touched up some problems with buildsystem.jsp
o changed CVS module formatting, removed trailing ant fluff and
re-formated the top of cvs.jsp
o added a quick start guide
o added a buildsystem faq (still needs more q to a)
o added the quick start, build system and SF project info page to the
developer navigation.
* eventually want to replace these nav links to a single Guides page,
which can list over all of them... but for now these are the big ones
developers will want to see.
o minor non-visual formatting changes to slogan and picateam
Revision ChangesPath
1.5 +55 -12newsite/src/docs/main.css
Index: main.css
===
RCS file: /cvsroot/jboss/newsite/src/docs/main.css,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- main.css 2001/10/05 19:00:04 1.4
+++ main.css 2001/11/17 04:19:12 1.5
@@ -2,19 +2,62 @@
* Style Sheet document for the new JBoss website.
*/
-/* $Id: main.css,v 1.4 2001/10/05 19:00:04 mnf999 Exp $ */
+/* $Id: main.css,v 1.5 2001/11/17 04:19:12 user57 Exp $ */
-.linkhead { font-family: Arial; font-size: 12px; color: #ff; font-weight:
bold; }
-.linkmenu { font-family: Arial; font-size: 12px; color: #0a0a0a; font-weight:
bold; text-decoration: none; }
-.head { font-family: Arial; font-size: 14px; color: #336633; font-weight:
bold; }
-.slogan { font-family: Arial; font-size: 15px; color: #338833; font-weight:
bold; }
-.text { font-family: Arial; font-size: 13px; color: #00; }
-.link { font-family: Arial; font-size: 13px; color: #404040; font-weight:
bold; }
-.copy { font-family: Arial; font-size: 11px; color: #808080; }
-.linkmenu:hover { color: #40; text-decoration: underline; }
-.copy:hover { color: #00; }
-.link:hover { color: #336633; }
-.label { font-weight: bold }
+.linkhead {
+ font-family: Arial;
+ font-size: 12px;
+ color: #ff;
+ font-weight: bold;
+}
+.linkmenu {
+ font-family: Arial;
+ font-size: 12px;
+ color: #0a0a0a;
+ font-weight: bold;
+ text-decoration: none;
+}
+.head {
+ font-family: Arial;
+ font-size: 14px;
+ color: #336633;
+ font-weight: bold;
+}
+.slogan {
+ font-family: Arial;
+ font-size: 15px;
+ color: #338833;
+ font-weight: bold;
+}
+.text {
+ font-family: Arial;
+ font-size: 13px;
+ color: #00;
+}
+.link {
+ font-family: Arial;
+ font-size: 13px;
+ color: #003399;
+ font-weight: bold;
+}
+.link:hover {
+ color: #336633;
+}
+.copy {
+ font-family: Arial;
+ font-size: 11px;
+ color: #808080;
+}
+.linkmenu:hover {
+ color: #40;
+ text-decoration: underline;
+}
+.copy:hover {
+ color: #00;
+}
+.label {
+ font-weight: bold
+}
/* Old stuff we keep around for reference */
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-463320 ] Finders not seeing updates
Bugs item #463320, was opened at 2001-09-20 13:09
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=463320group_id=22866
Category: JBossCMP
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 8
Submitted By: Tejaswi Kasturi (zedmanauk)
Assigned to: Andreas Schaefer (schaefera)
Summary: Finders not seeing updates
Initial Comment:
I'm seeing this problem with JBoss 2.4.1 (and 2.4.1a
and 2.2.2). This problem does NOT occur in 2.4.0, which
leads me to believe it was fixed and then broke again:
(This is all with CMP)
(1) Start a TX
(2) Update data on a bean (call it A, class MyBean)
(for ex., set LinkID to 2 where it was 1 before)
(3) Run a finder to retrieve all the MyBeans which
match a certain criteria. (for ex., find all MyBeans
where LinkID = 1).
The finder shows the state of the beans before the
update (for ex. the retrieved list still includes A,
even though its LinkID has changed and is no longer
equal to 1), even though it is in the same TX as the
update. I should see the state of the table after the
update.
JBoss 3.0.0alpha as of 9/20/2001 also has the correct
behavior, like 2.4.0. Here's a snippet of code that I'm
running in a transaction:
public void go(long ID, long linkID) {
try {
EJBTest ejbtest = getEJBTest(ID);
long origLinkID = ejbtest.getLinkID();
ejbtest.setLinkID(linkID);
Collection coll = getEJBTestByLinkID(origLinkID);
for (Iterator i = coll.iterator(); i.hasNext(); ) {
EJBTest test = (EJBTest) i.next();
System.out.println(ID: + test.getID() + linkID:
+ test.getLinkID());
}
}
catch ...
}
getEJBTest and getEJBTestByLinkID just invoke the
appropriate finders.
Starting with two entries:
ID=1, LinkID=1
ID=2, LinkID=1
I run go in a tx with parameters (1, 2).
In JBoss 2.4.0 (and 3.0.0alpha), the println returns:
ID: 2 linkID: 1
as it should
In JBoss 2.4.1 (and 2.4.1a) it returns:
ID: 1 linkID: 2
ID: 2 linkID: 1
which means the finder is not working correctly.
I've attached my jar file with the beans and source.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=463320group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 172 Successful tests: 135 Errors:23 Failures: 14 [time of test: 17 November 2001 5:25 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details 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 [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 187 Successful tests: 148 Errors:25 Failures: 14 [time of test: 17 November 2001 6:23 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details 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 [details not shown - as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite. Its easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/somepackage SomeClass.java
User: starksm Date: 01/11/16 22:39:04 Removed: src/main/org/somepackage Tag: Branch_2_4 SomeClass.java Log: Remove some garbage ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-478882 ] Connection Pool unstable
Bugs item #478882, was opened at 2001-11-06 14:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=478882group_id=22866 Category: JBossCX Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Doug Ferguson (thedug) Assigned to: Andreas Schaefer (schaefera) Summary: Connection Pool unstable Initial Comment: Sometimes after our system has been running for awhile one of our app servers might enter a strange state where the Connection Pool will keep returning an XAClientConnection that contains a null jdbc Connection. -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 12:23 Message: Logged In: YES user_id=70434 Please give more information about your problem and your environment incl. the JBoss version. Andy -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 12:21 Message: Logged In: YES user_id=70434 Please give more information about your problem and your environment incl. the JBoss version. Andy -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=478882group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-478882 ] Connection Pool unstable
Bugs item #478882, was opened at 2001-11-06 14:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=478882group_id=22866 Category: JBossCX Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Doug Ferguson (thedug) Assigned to: Andreas Schaefer (schaefera) Summary: Connection Pool unstable Initial Comment: Sometimes after our system has been running for awhile one of our app servers might enter a strange state where the Connection Pool will keep returning an XAClientConnection that contains a null jdbc Connection. -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 12:24 Message: Logged In: YES user_id=70434 Please give more information about your problem and your environment incl. the JBoss version. Andy -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 12:23 Message: Logged In: YES user_id=70434 Please give more information about your problem and your environment incl. the JBoss version. Andy -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 12:21 Message: Logged In: YES user_id=70434 Please give more information about your problem and your environment incl. the JBoss version. Andy -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=478882group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-478882 ] Connection Pool unstable
Bugs item #478882, was opened at 2001-11-06 14:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=478882group_id=22866 Category: JBossCX Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Doug Ferguson (thedug) Assigned to: Andreas Schaefer (schaefera) Summary: Connection Pool unstable Initial Comment: Sometimes after our system has been running for awhile one of our app servers might enter a strange state where the Connection Pool will keep returning an XAClientConnection that contains a null jdbc Connection. -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 12:26 Message: Logged In: YES user_id=70434 Please give more information about your problem and your environment incl. the JBoss version. Andy -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 12:24 Message: Logged In: YES user_id=70434 Please give more information about your problem and your environment incl. the JBoss version. Andy -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 12:23 Message: Logged In: YES user_id=70434 Please give more information about your problem and your environment incl. the JBoss version. Andy -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 12:21 Message: Logged In: YES user_id=70434 Please give more information about your problem and your environment incl. the JBoss version. Andy -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=478882group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-463320 ] Finders not seeing updates
Bugs item #463320, was opened at 2001-09-20 13:09
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=463320group_id=22866
Category: JBossCMP
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 8
Submitted By: Tejaswi Kasturi (zedmanauk)
Assigned to: Andreas Schaefer (schaefera)
Summary: Finders not seeing updates
Initial Comment:
I'm seeing this problem with JBoss 2.4.1 (and 2.4.1a
and 2.2.2). This problem does NOT occur in 2.4.0, which
leads me to believe it was fixed and then broke again:
(This is all with CMP)
(1) Start a TX
(2) Update data on a bean (call it A, class MyBean)
(for ex., set LinkID to 2 where it was 1 before)
(3) Run a finder to retrieve all the MyBeans which
match a certain criteria. (for ex., find all MyBeans
where LinkID = 1).
The finder shows the state of the beans before the
update (for ex. the retrieved list still includes A,
even though its LinkID has changed and is no longer
equal to 1), even though it is in the same TX as the
update. I should see the state of the table after the
update.
JBoss 3.0.0alpha as of 9/20/2001 also has the correct
behavior, like 2.4.0. Here's a snippet of code that I'm
running in a transaction:
public void go(long ID, long linkID) {
try {
EJBTest ejbtest = getEJBTest(ID);
long origLinkID = ejbtest.getLinkID();
ejbtest.setLinkID(linkID);
Collection coll = getEJBTestByLinkID(origLinkID);
for (Iterator i = coll.iterator(); i.hasNext(); ) {
EJBTest test = (EJBTest) i.next();
System.out.println(ID: + test.getID() + linkID:
+ test.getLinkID());
}
}
catch ...
}
getEJBTest and getEJBTestByLinkID just invoke the
appropriate finders.
Starting with two entries:
ID=1, LinkID=1
ID=2, LinkID=1
I run go in a tx with parameters (1, 2).
In JBoss 2.4.0 (and 3.0.0alpha), the println returns:
ID: 2 linkID: 1
as it should
In JBoss 2.4.1 (and 2.4.1a) it returns:
ID: 1 linkID: 2
ID: 2 linkID: 1
which means the finder is not working correctly.
I've attached my jar file with the beans and source.
--
Comment By: Tejaswi Kasturi (zedmanauk)
Date: 2001-11-16 13:33
Message:
Logged In: YES
user_id=288111
2.4.3 is also exhibiting incorrect behavior.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=463320group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-463320 ] Finders not seeing updates
Bugs item #463320, was opened at 2001-09-20 13:09
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=463320group_id=22866
Category: JBossCMP
Group: v2.4 (stable)
Status: Closed
Resolution: None
Priority: 8
Submitted By: Tejaswi Kasturi (zedmanauk)
Assigned to: Andreas Schaefer (schaefera)
Summary: Finders not seeing updates
Initial Comment:
I'm seeing this problem with JBoss 2.4.1 (and 2.4.1a
and 2.2.2). This problem does NOT occur in 2.4.0, which
leads me to believe it was fixed and then broke again:
(This is all with CMP)
(1) Start a TX
(2) Update data on a bean (call it A, class MyBean)
(for ex., set LinkID to 2 where it was 1 before)
(3) Run a finder to retrieve all the MyBeans which
match a certain criteria. (for ex., find all MyBeans
where LinkID = 1).
The finder shows the state of the beans before the
update (for ex. the retrieved list still includes A,
even though its LinkID has changed and is no longer
equal to 1), even though it is in the same TX as the
update. I should see the state of the table after the
update.
JBoss 3.0.0alpha as of 9/20/2001 also has the correct
behavior, like 2.4.0. Here's a snippet of code that I'm
running in a transaction:
public void go(long ID, long linkID) {
try {
EJBTest ejbtest = getEJBTest(ID);
long origLinkID = ejbtest.getLinkID();
ejbtest.setLinkID(linkID);
Collection coll = getEJBTestByLinkID(origLinkID);
for (Iterator i = coll.iterator(); i.hasNext(); ) {
EJBTest test = (EJBTest) i.next();
System.out.println(ID: + test.getID() + linkID:
+ test.getLinkID());
}
}
catch ...
}
getEJBTest and getEJBTestByLinkID just invoke the
appropriate finders.
Starting with two entries:
ID=1, LinkID=1
ID=2, LinkID=1
I run go in a tx with parameters (1, 2).
In JBoss 2.4.0 (and 3.0.0alpha), the println returns:
ID: 2 linkID: 1
as it should
In JBoss 2.4.1 (and 2.4.1a) it returns:
ID: 1 linkID: 2
ID: 2 linkID: 1
which means the finder is not working correctly.
I've attached my jar file with the beans and source.
--
Comment By: Bill Burke (patriot1burke)
Date: 2001-11-16 13:41
Message:
Logged In: YES
user_id=176497
This is fixed in 2.4.4. It is my fault. I missed this
when I did the backmerge from 3.0 to 2.4.1. Sorry. 2.4.4
will be released soon.
--
Comment By: Tejaswi Kasturi (zedmanauk)
Date: 2001-11-16 13:33
Message:
Logged In: YES
user_id=288111
2.4.3 is also exhibiting incorrect behavior.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=463320group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-459320 ] TransactionRolledBackException
Bugs item #459320, was opened at 2001-09-06 14:28
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=459320group_id=22866
Category: JBossServer
Group: v2.2.2 (stable)
Status: Open
Resolution: None
Priority: 9
Submitted By: Paul Rowe (boxhead)
Assigned to: Andreas Schaefer (schaefera)
Summary: TransactionRolledBackException
Initial Comment:
Disregard previous bug. This is the same bug (I just
assigned myself a SourceForge ID). I sporadically get
TransactionRolledBackExceptions while reading my BMP
EJB's. I would get a deadlock for about 10 minutes
and then this exception would occur. Below is a debug
trace (the javax.transactionrollback exception is in
there), along with oodles of indo (in short, mysql,
linux, jdk1.3.1). Attached is a PDF describing my
system architecture.
ERROR:
com.boxhead.chess.controller.ApplicationController.proc
essdestselectedAction
():this=com.boxhead.chess.controller.ApplicationControl
ler[currentState=SelectDestinationOfPiece
DEBUGFLAG=false CONSTRUCTION_VALIDATION=false
MINIMIZE_MEMORY_USE=false
sourceServlet=/game/GameServlet forwardCount=0
dataObjectError=null currentlyProcessing=true
localAction=null useCache={} pageElements=null
currentlyExecutingAction=destselected
cancelAction=false brandNew=false
currentDataObject=null parameterlessRequest=false
precompile=false userLanguage=en_US
csl=com.boxhead.framework.controller.ControllerSessionL
istener[6 63.74.153.130]
csi=com.boxhead.framework.controller.ControllerSessionI
nfo[6 requestNumber=5 active=true
remoteAddr=63.74.153.130
adData=com.boxhead.authen.html.dataobject.AuthenData
[fields=com.boxhead.framework.html.dataobject.DataField
List[dataFields=
{userid=com.boxhead.framework.html.dataobject.DataField
[com.boxhead.authen.html.dataelement.UserIdSelection=Iv
[EMAIL PROTECTED] {true true}
isPasswordField=false],
password=com.boxhead.framework.html.dataobject.DataFiel
d[com.boxhead.authen.html.dataelement.PasswordField=
[NOT DISPLAYED] {true true} isPasswordField=true]}
fieldOrder=[userid, password]] true] newObject=true
activationTime=999808783814 sessionEndTime=-1
properLogout=false currentlyProcessing=true]]
EXCEPTION: com.boxhead.chess.types.ChessException:
com.boxhead.chess.ejb.stateless.ChessEJB.update():
Unknown error writing game to database:
com.boxhead.game.types.GameSystemException:
com.boxhead.game.ejb.stateless.GameEJB.getGame
(200109061223130351): Failure operating on an entity
bean:
javax.transaction.TransactionRolledbackException:
Transaction marked for rollback, possibly a timeout;
nested exception is:
java.lang.RuntimeException: Transaction marked for
rollback, possibly a timeout
EXCEPTION: com.boxhead.chess.types.ChessException:
com.boxhead.chess.ejb.stateless.ChessEJB.update():
Unknown error writing game to database:
com.boxhead.game.types.GameSystemException:
com.boxhead.game.ejb.stateless.GameEJB.getGame
(200109061223130351): Failure operating on an entity
bean:
javax.transaction.TransactionRolledbackException:
Transaction marked for rollback, possibly a timeout;
nested exception is:
java.lang.RuntimeException: Transaction marked for
rollback, possibly a timeout
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro
mServer(StreamRemoteCall.java:245)
at sun.rmi.transport.StreamRemoteCall.executeCall
(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke
(UnicastRef.java:122)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_
Stub.invoke(Unknown Source)
at
org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionP
roxy.invoke(StatelessSessionProxy.java:188)
at $Proxy5.update(Unknown Source)
at
com.boxhead.chess.controller.ApplicationController.proc
essdestselectedAction(ApplicationController.java:431)
at java.lang.reflect.Method.invoke(Native Method)
at
com.boxhead.framework.controller.HTTPController.invokeM
ethod(HTTPController.java:945)
at
com.boxhead.framework.controller.HTTPController.invokeA
ction(HTTPController.java:876)
at
com.boxhead.framework.controller.HTTPController.process
State(HTTPController.java:665)
at
com.boxhead.framework.controller.SessionController.proc
essState(SessionController.java:85)
at
com.boxhead.framework.controller.HTTPController.process
(HTTPController.java:200)
at
com.boxhead.framework.controller.SessionController.proc
ess(SessionController.java:64)
at
com.boxhead.framework.controller.servlet.ControllerServ
let.serviceHTTPControllerRequest
(ControllerServlet.java:362)
at
com.boxhead.framework.controller.servlet.ControllerServ
let.serviceLoggedHTTPControllerRequest
(ControllerServlet.java:200)
at
com.boxhead.framework.controller.servlet.ControllerServ
let.service(ControllerServlet.java:167)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at org.apache.tomcat.core.ServletWrapper.doService
(ServletWrapper.java:405)
at org.apache.tomcat.core.Handler.service
(Handler.java:287)
at org.apache.tomcat.core.ServletWrapper.service
[JBoss-dev] [ jboss-Bugs-474977 ] run.sh fails on Mac OS X
Bugs item #474977, was opened at 2001-10-25 10:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=474977group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Matthew Bishop (mattbishop) Assigned to: Andreas Schaefer (schaefera) Summary: run.sh fails on Mac OS X Initial Comment: The run.sh script in JBoss 2.4.1a and 2.4.3 incorrectly identifies a HotSpot Server VM and then tries to instantiate the VM with the '-server' option. This fails if the VM is indeed a HotSpot Client VM and not the server variety. Mac OS X does not ship with a server HotSpot, so the run.sh script fails when it tries to instantiate the VM. Here is a sample output: [localhost:/J2EE-servers/jboss/bin] matt% sh run.sh Unrecognized option: -server Could not create the Java virtual machine. Here is the output from Mac OS X 10.1 when checking the version: [localhost:/J2EE-servers/jboss/bin] matt% java -version java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-root-010902-18:51) Java HotSpot(TM) Client VM (build 1.3.1, mixed mode) My workaround is to edit the run.sh script and remove the $HOTSPOT variable from the instantiation line. -- Comment By: Andreas Schaefer (schaefera) Date: 2001-11-16 15:23 Message: Logged In: YES user_id=70434 Current CVS Branch_2_4 contains the fix. Andy -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=474977group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
