|
List Info
Thread: Re: hibernate 3.3.0 upgrade, slf4j introduction into jbossas
|
|
| Re: hibernate 3.3.0 upgrade, slf4j
introduction into jbossas |

|
2008-05-05 08:11:50 |
I'm a bit hazy on the details but I understand that some
logging frameworks
allow you to subclass a base logger class, and some don't -
so if you do so
it's really difficult to properly weave in the appropriate
substitution.
Last time I heard, Trustin still didn't have a solution to
the problem.
Have you already made the switch to JDK logging in the
jbossas core? If
so, is there a sensible LogManager yet?
Also, do we need to do anything funky like support different
configurations
on a per-deployment basis? I am under the impression that
Glassfish does
this, but I haven't figured out the details yet.
For configurations, I get what you're saying - though I
imagine there's
probably users out there who want to use their own logging
framework and
configuration in certain deployments, so I think we'd need a
way to support
that - maybe just by detecting the presence of a logging
implementation in
the deployment or something.
Otherwise, based on what I know of the various logging
configuration
formats, we could probably just rewrite the logging
configuration into a
bean deployment that just uses the JDK logging API to
acquire and configure
Logger and Handler instances, rather than try to use the
stupid properties
system that the default LogManager uses.
- DML
On 05/04/2008 02:42 PM, Scott Stark wrote:
> All that I can recall as a reasonable compromise was to
simply move to
> the jdk logging with the replacement logging handlers
based on the log4j
> type of appenders I ported over when previously looking
at this problem.
> Trustin has since introduced log2log, we could always
use jboss retro to
> map framework X onto the jbossas core, but that does
not cover the
> framwork X configuration files.
>
> How I can see the mc and jbossas deployment framework
fitting in is by
> rewriting the logging system X config files onto the
current jbossas
> implementation if that is desired. The problem always
is whether the
> logging in question is part of a user application, or a
jbossas
> framework. In reality I only see jdk logging for the
server frameworks
> and other frameworks wanting to integrate with the
server logs having a
> jdk logger option, or an adaptor.
>
> What are the log2log issues showing up?
>
> David M. Lloyd wrote:
>> Well, that's a good project, but bytecode weaving
seems like a pretty
>> heavy-duty solution to a simple problem.
>>
>> The basic problem is, people (within JBoss and
without) are going to
>> use the frameworks they're going to use. How much
effort is it to
>> adapt log2log (which has already run into some
interesting technical
>> dilemmas) to another framework, versus just adding
another API
>> facade? It seems like the microcontainer arch
would be perfectly
>> suited towards auto-wiring the appropriate logging
API.
>>
>> Wouldn't it be nice if we could say, "deploy
your app in
>> JBossAS/JBossMC and it will *just work*, regardless
of what logging
>> frameworks are being used by what"?
>>
>> - DML
>>
>> On 05/02/2008 01:41 PM, Ales Justin wrote:
>>> What about if we used this:
>>> - https://svn
.jboss.org/repos/log2log/trunk
>>> with-in one of our deployers, and you could
mark certain deployments
>>> as being 'dragged' through Log2Log to
'clean-up' logging?
>>>
>>> Steve Ebersole wrote:
>>>> I apologize for the tone in my last
response. The original thread
>>>> was frustrating enough, and here it is
being relived. I let that
>>>> frustration get to me when I should not
have.
>>>>
>>>> On May 2, 2008, at 12:12 PM, Steve Ebersole
wrote:
>>>>
>>>>> I cannot help that AS seems to think
that every piece of technology
>>>>> needs to be complete re-written in
house. Y'all have you're own
>>>>> logging framework, great, add it to the
other 50 out there.
>>>>>
>>>>> The part that you are missing is that
Hibernate is first and
>>>>> foremost a standalone library. And in
terms of integration, I have
>>>>> to consider integration with many
containers. I'm sure they all
>>>>> want jboss-logging as the 'yet another
logging api' in their
>>>>> environments as well.
>>>>>
>>>>> I used to use commons-logging which had
a very specific problem
>>>>> that slf4j solves in a unique way *on
any platform*...
>>>>>
>>>>> If you recall, I asked about
experiences using jboss-logging in
>>>>> environments other than within JBoss AS
and (in keeping with the
>>>>> general theme of that thread) got no
replies to the question asked:
>>>>> http://lists.jboss.org/pipermail/jboss-d
evelopment/2007-July/010398.html
>>>>>
>>>>>
>>>>>
>>>>> On May 2, 2008, at 11:30 AM, Scott
Stark wrote:
>>>>>
>>>>>> And we said sure, introduce yet
another logging api?
>>>>>>
>>>>>> Steve Ebersole wrote:
>>>>>>> I initiated that very
discussion on this very list almost a year
>>>>>>> ago ;)
>>>>>>>
>>>>>>> On May 2, 2008, at 11:15 AM,
Paul Gier wrote:
>>>>>>>
>>>>>>>> I upgraded this based on
JBAS-5133 and Steve's request. I can
>>>>>>>> switch it back to the old
version if that's what is needed.
>>>>>>>>
>>>>>>>>
>>>>>>>> Scott Stark wrote:
>>>>>>>>> Why was hibernate
updated to 3.3.0 in jbossas trunk, and why is
>>>>>>>>> this pulling in yet
another logging framework? This needs to be
>>>>>>>>> reverted, and why there
has to be yet another logging framework
>>>>>>>>> dependency brought in
explained.
>>>>>>>>> *** CONTEXTS IN ERROR:
Name -> Error
>>>>>>>>>
vfsfile:/media/disk/workspace/tck5/jboss-5.0.0.CR1/server/ct
s/tmp/jsr88/ejb3_annotations_entity_vehicles.ear
>>>>>>>>> ->
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
>>>>>>>>>
_______________________________________________
>>>>>>>>> jboss-development
mailing list
>>>>>>>>> jboss-development lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------
>>>>>>> Steve Ebersole
>>>>>>>
>>>>>>> Project Lead
>>>>>>> http://hibernate.org
>>>>>>> steve hibernate.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
_______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>
>>>>>>
_______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>
>>>>>
>>>>> -----------------------------
>>>>> Steve Ebersole
>>>>>
>>>>> Project Lead
>>>>> http://hibernate.org
>>>>> steve hibernate.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> -----------------------------
>>>> Steve Ebersole
>>>>
>>>> Project Lead
>>>> http://hibernate.org
>>>> steve hibernate.org
>>>>
>>>>
>>>>
>>>>
>>>>
_______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>
>>>
_______________________________________________
>>> jboss-development mailing list
>>> jboss-development lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>
> _______________________________________________
> jboss-development mailing list
> jboss-development lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
_______________________________________________
jboss-development mailing list
jboss-development lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
|
|
| Re: hibernate 3.3.0 upgrade, slf4j
introduction into jbossas |

|
2008-05-05 08:20:34 |
Shame on Steve for introducing yet another logging
framework. All
you're gonna do is piss off every JBoss AS user that wants
to debug
Hibernate and has to figure out shitLog4j.
I hate to single you out, but this is another example of the
ivory
tower, silo development we have at JBoss where nobody cares
about how
they fit into the bigger picture. The world if bigger than
Hibernate.
David M. Lloyd wrote:
> I'm a bit hazy on the details but I understand that
some logging
> frameworks allow you to subclass a base logger class,
and some don't -
> so if you do so it's really difficult to properly weave
in the
> appropriate substitution. Last time I heard, Trustin
still didn't have a
> solution to the problem.
>
> Have you already made the switch to JDK logging in the
jbossas core? If
> so, is there a sensible LogManager yet?
>
> Also, do we need to do anything funky like support
different
> configurations on a per-deployment basis? I am under
the impression
> that Glassfish does this, but I haven't figured out the
details yet.
>
> For configurations, I get what you're saying - though I
imagine there's
> probably users out there who want to use their own
logging framework and
> configuration in certain deployments, so I think we'd
need a way to
> support that - maybe just by detecting the presence of
a logging
> implementation in the deployment or something.
>
> Otherwise, based on what I know of the various logging
configuration
> formats, we could probably just rewrite the logging
configuration into a
> bean deployment that just uses the JDK logging API to
acquire and
> configure Logger and Handler instances, rather than try
to use the
> stupid properties system that the default LogManager
uses.
>
> - DML
>
> On 05/04/2008 02:42 PM, Scott Stark wrote:
>> All that I can recall as a reasonable compromise
was to simply move to
>> the jdk logging with the replacement logging
handlers based on the
>> log4j type of appenders I ported over when
previously looking at this
>> problem. Trustin has since introduced log2log, we
could always use
>> jboss retro to map framework X onto the jbossas
core, but that does
>> not cover the framwork X configuration files.
>>
>> How I can see the mc and jbossas deployment
framework fitting in is by
>> rewriting the logging system X config files onto
the current jbossas
>> implementation if that is desired. The problem
always is whether the
>> logging in question is part of a user application,
or a jbossas
>> framework. In reality I only see jdk logging for
the server frameworks
>> and other frameworks wanting to integrate with the
server logs having
>> a jdk logger option, or an adaptor.
>>
>> What are the log2log issues showing up?
>>
>> David M. Lloyd wrote:
>>> Well, that's a good project, but bytecode
weaving seems like a pretty
>>> heavy-duty solution to a simple problem.
>>>
>>> The basic problem is, people (within JBoss and
without) are going to
>>> use the frameworks they're going to use. How
much effort is it to
>>> adapt log2log (which has already run into some
interesting technical
>>> dilemmas) to another framework, versus just
adding another API
>>> facade? It seems like the microcontainer arch
would be perfectly
>>> suited towards auto-wiring the appropriate
logging API.
>>>
>>> Wouldn't it be nice if we could say,
"deploy your app in
>>> JBossAS/JBossMC and it will *just work*,
regardless of what logging
>>> frameworks are being used by what"?
>>>
>>> - DML
>>>
>>> On 05/02/2008 01:41 PM, Ales Justin wrote:
>>>> What about if we used this:
>>>> - https://svn
.jboss.org/repos/log2log/trunk
>>>> with-in one of our deployers, and you could
mark certain deployments
>>>> as being 'dragged' through Log2Log to
'clean-up' logging?
>>>>
>>>> Steve Ebersole wrote:
>>>>> I apologize for the tone in my last
response. The original thread
>>>>> was frustrating enough, and here it is
being relived. I let that
>>>>> frustration get to me when I should not
have.
>>>>>
>>>>> On May 2, 2008, at 12:12 PM, Steve
Ebersole wrote:
>>>>>
>>>>>> I cannot help that AS seems to
think that every piece of
>>>>>> technology needs to be complete
re-written in house. Y'all have
>>>>>> you're own logging framework,
great, add it to the other 50 out
>>>>>> there.
>>>>>>
>>>>>> The part that you are missing is
that Hibernate is first and
>>>>>> foremost a standalone library. And
in terms of integration, I
>>>>>> have to consider integration with
many containers. I'm sure they
>>>>>> all want jboss-logging as the 'yet
another logging api' in their
>>>>>> environments as well.
>>>>>>
>>>>>> I used to use commons-logging which
had a very specific problem
>>>>>> that slf4j solves in a unique way
*on any platform*...
>>>>>>
>>>>>> If you recall, I asked about
experiences using jboss-logging in
>>>>>> environments other than within
JBoss AS and (in keeping with the
>>>>>> general theme of that thread) got
no replies to the question
>>>>>> asked:
>>>>>> http://lists.jboss.org/pipermail/jboss-d
evelopment/2007-July/010398.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> On May 2, 2008, at 11:30 AM, Scott
Stark wrote:
>>>>>>
>>>>>>> And we said sure, introduce yet
another logging api?
>>>>>>>
>>>>>>> Steve Ebersole wrote:
>>>>>>>> I initiated that very
discussion on this very list almost a year
>>>>>>>> ago ;)
>>>>>>>>
>>>>>>>> On May 2, 2008, at 11:15
AM, Paul Gier wrote:
>>>>>>>>
>>>>>>>>> I upgraded this based
on JBAS-5133 and Steve's request. I can
>>>>>>>>> switch it back to the
old version if that's what is needed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Scott Stark wrote:
>>>>>>>>>> Why was hibernate
updated to 3.3.0 in jbossas trunk, and why
>>>>>>>>>> is this pulling in
yet another logging framework? This needs
>>>>>>>>>> to be reverted, and
why there has to be yet another logging
>>>>>>>>>> framework
dependency brought in explained.
>>>>>>>>>> *** CONTEXTS IN
ERROR: Name -> Error
>>>>>>>>>>
vfsfile:/media/disk/workspace/tck5/jboss-5.0.0.CR1/server/ct
s/tmp/jsr88/ejb3_annotations_entity_vehicles.ear
>>>>>>>>>> ->
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
>>>>>>>>>>
_______________________________________________
>>>>>>>>>> jboss-development
mailing list
>>>>>>>>>>
jboss-development lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
-----------------------------
>>>>>>>> Steve Ebersole
>>>>>>>>
>>>>>>>> Project Lead
>>>>>>>> http://hibernate.org
>>>>>>>> steve hibernate.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
_______________________________________________
>>>>>>>> jboss-development mailing
list
>>>>>>>> jboss-development lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>
>>>>>>>
_______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>
>>>>>>
>>>>>> -----------------------------
>>>>>> Steve Ebersole
>>>>>>
>>>>>> Project Lead
>>>>>> http://hibernate.org
>>>>>> steve hibernate.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -----------------------------
>>>>> Steve Ebersole
>>>>>
>>>>> Project Lead
>>>>> http://hibernate.org
>>>>> steve hibernate.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
_______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>
>>>>
_______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>
_______________________________________________
>>> jboss-development mailing list
>>> jboss-development lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
> _______________________________________________
> jboss-development mailing list
> jboss-development lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral
.com
_______________________________________________
jboss-development mailing list
jboss-development lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
|
|
| Re: hibernate 3.3.0 upgrade, slf4j
introduction into jbossas |
  United States |
2008-05-05 14:17:51 |
Another option might be dynamic replacement of the logging
framework
with a different impl altogether. There is an example of
this in
allowing code using commons-logging to remain unchanged, and
a
different implementation of the commons-logging APIs to be
substituted
with slf4j logging: http://day-to-day-stuff.blogspot.com/20
07/07/no-more-commons-logging.html
In fact I use this setup already in the hibernate
testsuite to
account for other libraries (commons-collections, etc) which
use
commons-logging and have them dynamically use my slf4j
setup.
On May 5, 2008, at 8:11 AM, David M. Lloyd wrote:
> I'm a bit hazy on the details but I understand that
some logging
> frameworks allow you to subclass a base logger class,
and some don't
> - so if you do so it's really difficult to properly
weave in the
> appropriate substitution. Last time I heard, Trustin
still didn't
> have a solution to the problem.
>
> Have you already made the switch to JDK logging in the
jbossas
> core? If so, is there a sensible LogManager yet?
>
> Also, do we need to do anything funky like support
different
> configurations on a per-deployment basis? I am under
the impression
> that Glassfish does this, but I haven't figured out the
details yet.
>
> For configurations, I get what you're saying - though I
imagine
> there's probably users out there who want to use their
own logging
> framework and configuration in certain deployments, so
I think we'd
> need a way to support that - maybe just by detecting
the presence of
> a logging implementation in the deployment or
something.
>
> Otherwise, based on what I know of the various logging
configuration
> formats, we could probably just rewrite the logging
configuration
> into a bean deployment that just uses the JDK logging
API to acquire
> and configure Logger and Handler instances, rather than
try to use
> the stupid properties system that the default
LogManager uses.
>
> - DML
>
> On 05/04/2008 02:42 PM, Scott Stark wrote:
>> All that I can recall as a reasonable compromise
was to simply move
>> to the jdk logging with the replacement logging
handlers based on
>> the log4j type of appenders I ported over when
previously looking
>> at this problem. Trustin has since introduced
log2log, we could
>> always use jboss retro to map framework X onto the
jbossas core,
>> but that does not cover the framwork X
configuration files.
>> How I can see the mc and jbossas deployment
framework fitting in is
>> by rewriting the logging system X config files onto
the current
>> jbossas implementation if that is desired. The
problem always is
>> whether the logging in question is part of a user
application, or a
>> jbossas framework. In reality I only see jdk
logging for the server
>> frameworks and other frameworks wanting to
integrate with the
>> server logs having a jdk logger option, or an
adaptor.
>> What are the log2log issues showing up?
>> David M. Lloyd wrote:
>>> Well, that's a good project, but bytecode
weaving seems like a
>>> pretty heavy-duty solution to a simple
problem.
>>>
>>> The basic problem is, people (within JBoss and
without) are going
>>> to use the frameworks they're going to use.
How much effort is it
>>> to adapt log2log (which has already run into
some interesting
>>> technical dilemmas) to another framework,
versus just adding
>>> another API facade? It seems like the
microcontainer arch would
>>> be perfectly suited towards auto-wiring the
appropriate logging API.
>>>
>>> Wouldn't it be nice if we could say,
"deploy your app in JBossAS/
>>> JBossMC and it will *just work*, regardless of
what logging
>>> frameworks are being used by what"?
>>>
>>> - DML
>>>
>>> On 05/02/2008 01:41 PM, Ales Justin wrote:
>>>> What about if we used this:
>>>> - https://svn
.jboss.org/repos/log2log/trunk
>>>> with-in one of our deployers, and you could
mark certain
>>>> deployments as being 'dragged' through
Log2Log to 'clean-up'
>>>> logging?
>>>>
>>>> Steve Ebersole wrote:
>>>>> I apologize for the tone in my last
response. The original
>>>>> thread was frustrating enough, and here
it is being relived. I
>>>>> let that frustration get to me when I
should not have.
>>>>>
>>>>> On May 2, 2008, at 12:12 PM, Steve
Ebersole wrote:
>>>>>
>>>>>> I cannot help that AS seems to
think that every piece of
>>>>>> technology needs to be complete
re-written in house. Y'all
>>>>>> have you're own logging framework,
great, add it to the other
>>>>>> 50 out there.
>>>>>>
>>>>>> The part that you are missing is
that Hibernate is first and
>>>>>> foremost a standalone library. And
in terms of integration, I
>>>>>> have to consider integration with
many containers. I'm sure
>>>>>> they all want jboss-logging as the
'yet another logging api' in
>>>>>> their environments as well.
>>>>>>
>>>>>> I used to use commons-logging which
had a very specific problem
>>>>>> that slf4j solves in a unique way
*on any platform*...
>>>>>>
>>>>>> If you recall, I asked about
experiences using jboss-logging in
>>>>>> environments other than within
JBoss AS and (in keeping with
>>>>>> the general theme of that thread)
got no replies to the
>>>>>> question asked: http://lists.jboss.org/pipermail/jboss-d
evelopment/2007-July/010398.html
>>>>>>
>>>>>>
>>>>>> On May 2, 2008, at 11:30 AM, Scott
Stark wrote:
>>>>>>
>>>>>>> And we said sure, introduce yet
another logging api?
>>>>>>>
>>>>>>> Steve Ebersole wrote:
>>>>>>>> I initiated that very
discussion on this very list almost a
>>>>>>>> year ago ;)
>>>>>>>>
>>>>>>>> On May 2, 2008, at 11:15
AM, Paul Gier wrote:
>>>>>>>>
>>>>>>>>> I upgraded this based
on JBAS-5133 and Steve's request. I
>>>>>>>>> can switch it back to
the old version if that's what is
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Scott Stark wrote:
>>>>>>>>>> Why was hibernate
updated to 3.3.0 in jbossas trunk, and
>>>>>>>>>> why is this pulling
in yet another logging framework? This
>>>>>>>>>> needs to be
reverted, and why there has to be yet another
>>>>>>>>>> logging framework
dependency brought in explained.
>>>>>>>>>> *** CONTEXTS IN
ERROR: Name -> Error
>>>>>>>>>>
vfsfile:/media/disk/workspace/tck5/jboss-5.0.0.CR1/server/
>>>>>>>>>>
cts/tmp/jsr88/ejb3_annotations_entity_vehicles.ear ->
>>>>>>>>>>
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
>>>>>>>>>>
_______________________________________________
>>>>>>>>>> jboss-development
mailing list
>>>>>>>>>>
jboss-development lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
-----------------------------
>>>>>>>> Steve Ebersole
>>>>>>>>
>>>>>>>> Project Lead
>>>>>>>> http://hibernate.org
>>>>>>>> steve hibernate.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
_______________________________________________
>>>>>>>> jboss-development mailing
list
>>>>>>>> jboss-development lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>
>>>>>>>
_______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>
>>>>>>
>>>>>> -----------------------------
>>>>>> Steve Ebersole
>>>>>>
>>>>>> Project Lead
>>>>>> http://hibernate.org
>>>>>> steve hibernate.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -----------------------------
>>>>> Steve Ebersole
>>>>>
>>>>> Project Lead
>>>>> http://hibernate.org
>>>>> steve hibernate.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
_______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>
>>>>
_______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>
_______________________________________________
>>> jboss-development mailing list
>>> jboss-development lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
> _______________________________________________
> jboss-development mailing list
> jboss-development lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
-----------------------------
Steve Ebersole
Project Lead
http://hibernate.org
steve hibernate.org
_______________________________________________
jboss-development mailing list
jboss-development lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
|
|
[1-3]
|
|