Nabble - EJB

Re: Container Type of SingletonContainer.

2008-10-06T23:49:32Z

Well I caught it because I was grouping the containers via type in the
portlet i am developing for geronimo. So the singleton container
appears under stateless containers.

Regards
Manu

On Tue, Oct 7, 2008 at 12:50 AM, David Blevins <david.blevins@...> wrote:

>
> On Oct 3, 2008, at 5:44 AM, Manu George wrote:
>
>> Hi,
>> The SingletonContainer has a type STATELESS. Shouldn't we have
>> another type for singleton?
>>
>
> Good catch. Seems that property of the container is only used for logging
> on startup so it was missed. Will have to make a mental note of that for
> next time.
>
> Thanks!
>
> -David
>
>

From forum: OpenEJB Dev

Re: batch reading with separate fetch size setting

2008-10-06T23:47:40Z

James,

There is no query hint to do this, feel free to log an enhancement request
for this.

done


You can configure this using the ReadAllQuery code API.

I'll give it a try, thank you




Kate Lain wrote:
> 
> James,
> 
> I have three related entities say A, B, C with an OneToMany mapping both
> between A - B and A - C . There is a need to read all the objects in a
> single query. Therefore i've defined a named query in A as
 follows:
> 
> @NamedQuery(
>     name = "A.findAll", 
>     query = "SELECT a FROM A a , 
>     hints = { 
>         @QueryHint(name = QueryHints.BATCH, value =
"a.bs"),
>         @QueryHint(name = QueryHints.BATCH, value =
"a.cs"),
>         @QueryHint(name = QueryHints.JDBC_FETCH_SIZE, value =
"500")
>     }
> )
> 
> As result I got about 500 objects for A, 5000 objects for B and 50000
> objects for C from the three queries (the one named and the two batch
> queries). Regarding the tuning of the jdbc fetch size I can only define a
> single value as query hint as far as I can gather. I take it that it will
> only taking effect for the A-query wouldn't it? How may I effect then
the
> fetch
 size for the batch queries. Or, I'm totally wrong here?
> 
> --- On Thu, 10/2/08, James Sutherland <jamesssss@...> wrote:
> From: James Sutherland <jamesssss@...>
> Subject: Re: [eclipselink-users] batch reading with separate fetch size
> setting
> To: eclipselink-users@...
> Date: Thursday, October 2, 2008, 6:57 AM
> 
> I'm not exactly sure I understand what you mean perhaps give an
example.
> 
> Assuming you want to set the fetch size of the nested batch queries, there
> is no easy way to do this.  However you could prepare() your query, then
> access the getBatchReadMappingQueries() that are generated to customize
> any
> of the nested batch queries.
> 
> 
> 
> Kate Lain wrote:
>> 
>> Hi,
>> 
>> 
>> 
>> for performance reasons I've optimized my
 queries using batch
reading
>> and fetch size tuning - but is there a way to set the fetch size
separate
>> per
>> batch query?
>> 
>> Thomas
>> 
> 


-----
---
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland 
http://www.eclipse.org/eclipselink/
 EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink 
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink , 
http://wiki.oracle.com/page/TopLink TopLink 
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink , 
http://www.nabble.com/EclipseLink-f26430.html EclipseLink 
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence 
-- 
View this message in context:
http://www.nabble.com/batch-reading-with-separate-fetch-size-setting-tp19767497p19839612.html
Sent from the EclipseLink - Users mailing list archive at
 Nabble.com.

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

From forum: EclipseLink - Users

AW: EclipseLink Performance Profiler configuration

2008-10-06T22:41:44Z

James,

now it all makes sense, thank you. Next time I'll check the bug list before.

> This is a current bug, see,
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=230921
>
> I should check this fix in this week to the 1.1 stream. In the mean time,
> you can set the profiler using a SessionCustomizer.
>
>>
>> I want to use the EclipseLink Performance Profiler. Following the
>> configuration instructions in the docs my settings in the persistence.xml
>> are as follows but I don't see any profiling output in my log.
>> ...
>> <property name="eclipselink.logging.level" value="INFO" />
>> <property name="eclipselink.logging.timestamp" value="true" />
>> <property name="eclipselink.logging.session" value="false" />
>> <property name="eclipselink.logging.thread" value="false" />
>>
>> <property name="eclipselink.profiler" value="PerformanceProfiler" />
>> ...
>> Changing the logging level has no effects - what I'm missing? I'm
>> wondering that there isn't a entry for property "eclipselink.profiler" in
>> the log as it will be for each of the other property entries - may be this
>> could be a hint, that there is something wrong with my configuration ...
>> for now I'm helpless.
>>
>>

-----
---
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
--
View this message in context: http://www.nabble.com/EclipseLink-Performance-Profiler-configuration-tp19839052p19839683.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

From forum: EclipseLink - Users

JPA CustomSequencing - uuid

2008-10-06T20:34:15Z

Anyone been able to make this work: http://wiki.eclipse.org/EclipseLink/Examples/JPA/CustomSequencing

I've followed the instruction in the above link but I am getting this error:

Exception [EclipseLink-28014] (Eclipse Persistence Services - 1.0.1 (Build 20080905)): org.eclipse.persistence.exceptions.EntityManagerSetupException
Exception Description: Exception was thrown while processing property [eclipselink.session.customizer] with value [eclipselink.example.UUIDSequence].
Internal Exception: java.lang.InstantiationException: eclipselink.example.UUIDSequence
at org.eclipse.persistence.exceptions.EntityManagerSetupException.failedWhileProcessingProperty(EntityManagerSetupException.java:178)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.processSessionCustomizer(EntityManagerSetupImpl.java:1222)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.updateServerSession(EntityManagerSetupImpl.java:1198)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:237)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.getServerSession(EntityManagerFactoryImpl.java:69)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:118)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:112)
at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:100)

Am I missing something here? Thanks.

From forum: EclipseLink - Users

Closing out CAY-1077

2008-10-06T16:04:22Z

I'm still looking for feedback on the relationship modeling dialog.
While I really don't like the single click semantics, I'm inclined to
withdraw my objections in the interest of closing the issue out.
Additional feedback in form of usability testing would be much
appreciated.

Thanks,
Kevin

From forum: Cayenne - Dev

[jira] Commented: (CAY-911) CM Usability: JComboBox Autocompletion

2008-10-06T15:46:12Z

[ https://issues.apache.org/cayenne/browse/CAY-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13142#action_13142 ]

Kevin Menard commented on CAY-911:
----------------------------------

Not looking to be a pain in the neck, but I would like to close this out if it is indeed fixed. MacOS X testers wanted.

> CM Usability: JComboBox Autocompletion
> --------------------------------------
>
> Key: CAY-911
> URL: https://issues.apache.org/cayenne/browse/CAY-911
> Project: Cayenne
> Issue Type: New Feature
> Components: CayenneModeler GUI
> Reporter: Thomas Bernhard
> Assignee: Kevin Menard
> Fix For: 3.0
>
> Attachments: patch-2008-05-11.txt, patch-CAY-911-25May.txt, patch-CAY-911-3.txt, patch-CAY-911.txt, screen.png, screen.png
>
>
> Please use JComBox with autocompletion in CM at least in places that are very repetitive like selecting Field Types.
> It is very simple to implement it and there are several extremly well documented examples how to do it. E.g.:
> http://www.orbital-computer.de/JComboBox/

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Cayenne - Dev

Re: Eclipse plugin & libraries

2008-10-06T15:45:31Z

Alex Grönholm wrote:
> It's just that the status of the server remains "republish" even after
> I publish. It should change to "synchronized" after a successful
> publish operation.

Ah, right. I'll have a look at that - thanks for letting me know.

Jon

From forum: OpenEJB Dev

Re: Eclipse plugin & libraries

2008-10-06T15:11:31Z

Jonathan Gallimore kirjoitti:

> Alex Grönholm wrote:
>> Ok, just make sure you add any and all the jars in that directory to
>> the project classpath, and not just a fixed set.
> Will do.
>> Also, it seems that the publish functionality is broken (nothing
>> happens when you try to publish). Can you verify this?
> Just done a test with a fresh install of the plugin on both Eclipse
> Europa and Ganymede, and done a deploy of our simple-stateless
> project, and it deployed ok. You should see something like the
> following in your openejb.log file:
>

It's just that the status of the server remains "republish" even after I
publish. It should change to "synchronized" after a successful publish
operation.

> 2008-10-06 20:55:02,765 - INFO - Configuring enterprise application:
> C:\Documents and Settings\Jon\Local Settings\Temp\oejb21426.jar
> 2008-10-06 20:55:02,781 - INFO - Enterprise application "C:\Documents
> and Settings\Jon\Local Settings\Temp\oejb21426.jar" loaded.
> 2008-10-06 20:55:02,812 - INFO - Assembling app: C:\Documents and
> Settings\Jon\Local Settings\Temp\oejb21426.jar
> 2008-10-06 20:55:02,812 - INFO - Jndi(name=CalculatorImplLocal) -->
> Ejb(deployment-id=CalculatorImpl)
> 2008-10-06 20:55:02,812 - INFO - Jndi(name=CalculatorImplRemote) -->
> Ejb(deployment-id=CalculatorImpl)
> 2008-10-06 20:55:02,812 - INFO - Created
> Ejb(deployment-id=CalculatorImpl, ejb-name=CalculatorImpl,
> container=My Stateless Container)
> 2008-10-06 20:55:02,812 - INFO - Deployed
> Application(path=C:\Documents and Settings\Jon\Local
> Settings\Temp\oejb21426.jar)
>
> Unfortunately nothing is echoed to the console at the moment. When we
> deploy, we create a temp file, and deploy by calling one of OpenEJBs
> own EJBs (if the server is running when the publish is done, this
> happens right away, otherwise it happens when the server starts). We
> don't copy anything to the openejb/apps folder as we've found suffers
> from locking issues when trying to undeploy / redeploy.
>
> If you don't see any output in your log (or you have an exception)
> please let us know as it might be a bug.
>
> Jon

From forum: OpenEJB Dev

Re: Eclipse plugin & libraries

2008-10-06T14:51:46Z

I've committed this change and updated the update site.

Jon

Jonathan Gallimore wrote:

> Hi Alex,
>
> Thanks for downloading the plugin and giving it a go. I guess at the
> moment, we'd regard it as beta. I'm currently working on a couple of
> final features and was then going to see if everybody thought it was
> ready for a release.
>
> In terms of the classpath, you're right, we only add openejb-client,
> javaee-api and optionally ejb31-api-experimental if you want it. It
> hasn't caused me any problems with testing (probably because I deploy
> to a standalone server and hit the beans as if I'm a remote client
> when I'm testing the plugin). I'm certainly happy to add the other
> jars in the openejb/lib folder to the project classpath. If there's no
> objections, I'll probably be able to get the change committed and the
> update site updated this evening.
>
> Jon
>
> Alex Grönholm wrote:
>> I recently installed the "Apache OpenEJB WTP Runtime 1.0.0" and found
>> that it only includes a few libraries when added to a project. In my
>> opinion, the runtime should add all of the libraries from openejb/lib
>> to the project, like the JBoss runtime does. This is necessary for,
>> among other things, unit testing since all of the server's requisites
>> must be on the classpath. I do not know the current state of affairs
>> with the plugin, so could someone comment on this please?
>

From forum: OpenEJB Dev

Re: Re: Version Class changes and the Manifest file

2008-10-06T14:21:44Z

The Plug-in Versioning Guidelines may be useful as a reference -
http://wiki.eclipse.org/index.php/Version_Numbering.

Neil

Tom Ware wrote:

> I guess we need to figure out if we would ever need 4 or more digits.
>
> Eric Gwin wrote:
>> Point taken, and I agree there could be confusion (though 1.1.1 would
>> look like 1.1.1.2991-SNAPSHOT or 1.1.1.3267 (release)).
>>
>> Therefore we should ALWAYS specify all the digits in our version. If
>> we are going to use a three number versioning scheme
>> (major).(minor).(bugfix), then we should always display the full
>> version.
>>
>> ie. 1.1.0.2984 and 1.1.1.3267
>>
>> -Eric
>>
>> Tom Ware wrote:
>>> I am concerned that will cause confusion at release time.
>>>
>>> If we're not careful, it may look like we just released version
>>> 1.1.2984. If at some point, we release version 1.1.1, it will look
>>> like version 1.1.2984 is more recent, when in fact it is less recent.
>>>
>>> Are these changes just for manifest files, or also for jar file naming?
>>>
>>> -Tom
>>>
>>> Eric Gwin wrote:
>>>> Sounds like Option 4:
>>>> -----------------------
>>>> It does distinguish revision from the version. Though I put the
>>>> period in because it blends it all into a single "Version Number".
>>>>
>>>> -Eric
>>>>
>>>> Tom Ware wrote:
>>>>> In your proposed solution, can we change the last "." to some
>>>>> other character
>>>>>
>>>>> e.g.
>>>>> 1.1-2312-SNAPSHOT
>>>>>
>>>>>
>>>>> Eric Gwin wrote:
>>>>>> Seems to be little interest on the topic, but I need to at least
>>>>>> pass this by the group so I'd like a vote today.
>>>>>>
>>>>>> I'll put a +1 next to my choice. If there are no other votes, I
>>>>>> guess it'll win by default.
>>>>>>
>>>>>> As an aside, MW currently uses something completely different. I
>>>>>> plan on setting this up to be consistent across EclipseLink
>>>>>>
>>>>>>
>>>>>> "Implementation-Version" in the manifest:
>>>>>> _Option 1:_
>>>>>> (version)(type)-(date).(revision) or (version)-(date).(revision)
>>>>>> 1.1SNAPSHOT-20081006.2312
>>>>>> 1.1M3-20081029.2739
>>>>>> 1.1-20081125.2984
>>>>>>
>>>>>> _Option 2:_
>>>>>> (version).(type).(revision) or (version).(date).(revision)
>>>>>> 1.1.20081006.2312
>>>>>> 1.1.M3.2739
>>>>>> 1.1.20081125.2984
>>>>>>
>>>>>> _Option 3 (+1):_
>>>>>> (version).(revision)-(type) or (version).(revision)
>>>>>> 1.1.2312-SNAPSHOT
>>>>>> 1.1.2739-M3
>>>>>> 1.1.2984
>>>>>>
>>>>>> The first option results in a string closest to what we currently
>>>>>> use (but with the addition of the revision).
>>>>>>
>>>>>> The second is the result of minimally changing the build
>>>>>> methodology.
>>>>>>
>>>>>> The third makes the most sense to me. It gives the version and a
>>>>>> unique build identifier (revision), is clean and easy to on the
>>>>>> eyes, yet still has distinctions for nightly, milestone and
>>>>>> release builds. However it diverges significantly from what we
>>>>>> currently use.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> -Eric
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> eclipselink-dev mailing list
>>>>>> eclipselink-dev@...
>>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>> _______________________________________________
>>>>> eclipselink-dev mailing list
>>>>> eclipselink-dev@...
>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>>
>>>> _______________________________________________
>>>> eclipselink-dev mailing list
>>>> eclipselink-dev@...
>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>> _______________________________________________
>>> eclipselink-dev mailing list
>>> eclipselink-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Re: Eclipse plugin & libraries

2008-10-06T13:33:28Z

Alex Grönholm wrote:
> Ok, just make sure you add any and all the jars in that directory to
> the project classpath, and not just a fixed set.
Will do.
> Also, it seems that the publish functionality is broken (nothing
> happens when you try to publish). Can you verify this?
Just done a test with a fresh install of the plugin on both Eclipse
Europa and Ganymede, and done a deploy of our simple-stateless project,
and it deployed ok. You should see something like the following in your
openejb.log file:

2008-10-06 20:55:02,765 - INFO - Configuring enterprise application:
C:\Documents and Settings\Jon\Local Settings\Temp\oejb21426.jar
2008-10-06 20:55:02,781 - INFO - Enterprise application "C:\Documents
and Settings\Jon\Local Settings\Temp\oejb21426.jar" loaded.
2008-10-06 20:55:02,812 - INFO - Assembling app: C:\Documents and
Settings\Jon\Local Settings\Temp\oejb21426.jar
2008-10-06 20:55:02,812 - INFO - Jndi(name=CalculatorImplLocal) -->
Ejb(deployment-id=CalculatorImpl)
2008-10-06 20:55:02,812 - INFO - Jndi(name=CalculatorImplRemote) -->
Ejb(deployment-id=CalculatorImpl)
2008-10-06 20:55:02,812 - INFO - Created
Ejb(deployment-id=CalculatorImpl, ejb-name=CalculatorImpl, container=My
Stateless Container)
2008-10-06 20:55:02,812 - INFO - Deployed Application(path=C:\Documents
and Settings\Jon\Local Settings\Temp\oejb21426.jar)

Unfortunately nothing is echoed to the console at the moment. When we
deploy, we create a temp file, and deploy by calling one of OpenEJBs own
EJBs (if the server is running when the publish is done, this happens
right away, otherwise it happens when the server starts). We don't copy
anything to the openejb/apps folder as we've found suffers from locking
issues when trying to undeploy / redeploy.

If you don't see any output in your log (or you have an exception)
please let us know as it might be a bug.

Jon

From forum: OpenEJB Dev

Re: Re: Version Class changes and the Manifest file

2008-10-06T13:24:38Z

I guess we need to figure out if we would ever need 4 or more digits.

Eric Gwin wrote:

> Point taken, and I agree there could be confusion (though 1.1.1 would
> look like 1.1.1.2991-SNAPSHOT or 1.1.1.3267 (release)).
>
> Therefore we should ALWAYS specify all the digits in our version. If we
> are going to use a three number versioning scheme
> (major).(minor).(bugfix), then we should always display the full version.
>
> ie. 1.1.0.2984 and 1.1.1.3267
>
> -Eric
>
> Tom Ware wrote:
>> I am concerned that will cause confusion at release time.
>>
>> If we're not careful, it may look like we just released version
>> 1.1.2984. If at some point, we release version 1.1.1, it will look
>> like version 1.1.2984 is more recent, when in fact it is less recent.
>>
>> Are these changes just for manifest files, or also for jar file naming?
>>
>> -Tom
>>
>> Eric Gwin wrote:
>>> Sounds like Option 4:
>>> -----------------------
>>> It does distinguish revision from the version. Though I put the
>>> period in because it blends it all into a single "Version Number".
>>>
>>> -Eric
>>>
>>> Tom Ware wrote:
>>>> In your proposed solution, can we change the last "." to some other
>>>> character
>>>>
>>>> e.g.
>>>> 1.1-2312-SNAPSHOT
>>>>
>>>>
>>>> Eric Gwin wrote:
>>>>> Seems to be little interest on the topic, but I need to at least
>>>>> pass this by the group so I'd like a vote today.
>>>>>
>>>>> I'll put a +1 next to my choice. If there are no other votes, I
>>>>> guess it'll win by default.
>>>>>
>>>>> As an aside, MW currently uses something completely different. I
>>>>> plan on setting this up to be consistent across EclipseLink
>>>>>
>>>>>
>>>>> "Implementation-Version" in the manifest:
>>>>> _Option 1:_
>>>>> (version)(type)-(date).(revision) or (version)-(date).(revision)
>>>>> 1.1SNAPSHOT-20081006.2312
>>>>> 1.1M3-20081029.2739
>>>>> 1.1-20081125.2984
>>>>>
>>>>> _Option 2:_
>>>>> (version).(type).(revision) or (version).(date).(revision)
>>>>> 1.1.20081006.2312
>>>>> 1.1.M3.2739
>>>>> 1.1.20081125.2984
>>>>>
>>>>> _Option 3 (+1):_
>>>>> (version).(revision)-(type) or (version).(revision)
>>>>> 1.1.2312-SNAPSHOT
>>>>> 1.1.2739-M3
>>>>> 1.1.2984
>>>>>
>>>>> The first option results in a string closest to what we currently
>>>>> use (but with the addition of the revision).
>>>>>
>>>>> The second is the result of minimally changing the build methodology.
>>>>>
>>>>> The third makes the most sense to me. It gives the version and a
>>>>> unique build identifier (revision), is clean and easy to on the
>>>>> eyes, yet still has distinctions for nightly, milestone and release
>>>>> builds. However it diverges significantly from what we currently use.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> -Eric
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> eclipselink-dev mailing list
>>>>> eclipselink-dev@...
>>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>> _______________________________________________
>>>> eclipselink-dev mailing list
>>>> eclipselink-dev@...
>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>>
>>> _______________________________________________
>>> eclipselink-dev mailing list
>>> eclipselink-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Re: Release plan for OpenEJB 3.0.x and 3.1

2008-10-06T13:22:40Z

FYI, I found a connection leak with the client side connection pool
support I added which affects failover. Working on getting that
fixed. Once in we should be able to wrap 3.1 up.

-David

On Oct 2, 2008, at 2:07 PM, David Blevins wrote:

> I started hacking on this last week but had to fly out for a funeral.
>
> I think we're in pretty good shape. JIRA is pretty much cleared out
> and I can't think of any missing bits or bobs that need to be done.
> I started running the assembly/test/build.xml script on mac and all
> looked good. Haven't had a chance yet to run it on linux or
> windows, if someone wants to do that, it'd be a big help.
>
> We can probably tag at this point.
>
> -David
>
> On Oct 2, 2008, at 12:58 PM, Dain Sundstrom wrote:
>
>> The next planned release is 3.1, and last I hear it was going to be
>> "soon".
>>
>> Historically, once we get started it takes a few weeks (3-4?) to
>> crank through some release candidates and get the final vote done.
>>
>> -dain
>>
>> On Oct 1, 2008, at 6:27 AM, Sami Jaber wrote:
>>
>>> +1
>>> It would be nice to have a release date ...
>>>
>>> Sami
>>>
>>> 2008/10/1 Henri Gomez <henri.gomez@...>
>>>
>>>> Hi to all,
>>>>
>>>> I'm new to OpenEJB and currently playing with 3.0 release (April
>>>> 2008)
>>>> and wonder if there is some release plan for 3.0.x (ie: 3.0.1).
>>>>
>>>> I'm concerned with the potential OpenEJB / JAX-WS problem fixed in
>>>> later September 2008 (in trunk) and I'd like to know it there
>>>> will be
>>>> a 3.0.1 sometime in the future.
>>>>
>>>> Thanks
>>>>
>>
>>
>
>

From forum: OpenEJB Dev

Re: Release plan for OpenEJB 3.0.x and 3.1

2008-10-06T13:21:13Z

If there was a good patch for it it'd be something we could slide in.

-David

On Oct 6, 2008, at 3:04 PM, rde8026 wrote:

>
> +1
> for support of either ActiveMQ 5.1 or 5.2. Not sure if it's to late
> for
> this but this would be a huge success since there some nice features
> in 5.1+
> that are not available in 4.1.1
>
>
> hgomez wrote:
>>
>>> I just rebuild an OpenEJB 3.1-SNAPSHOT and could see
>>>
>>> - OpenJPA 1.1.0 will be included, but I wonder if we could use also
>>> EclipseLink ?
>>>
>>> - CXF 2.0.4 is included and JAXB is 2.0.5. Could we use OpenEJB 3.1
>>> with JAXWS 2.1.4 and JAXB 2.1.8 ?
>>
>> And what about ActiveMQ ? Will it be the 4.1 or 5.1 (or 5.2) ?
>>
>> Thanks
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Release-plan-for-OpenEJB-3.0.x-and-3.1-tp19760036p19845352.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
>

From forum: OpenEJB Dev

RE: Re: Version Class changes and the Manifest file

2008-10-06T13:18:35Z

Out of these options I like #3.

However, I would prefer if the snapshots had a date on them. I don't think a date is necessary on the Milestones or releases

-----Original Message-----
From: Eric Gwin [mailto:eric.gwin@...]
Sent: Monday, October 06, 2008 2:53 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Re: Version Class changes and the Manifest file

Seems to be little interest on the topic, but I need to at least pass this by the group so I'd like a vote today.

I'll put a +1 next to my choice. If there are no other votes, I guess it'll win by default.

As an aside, MW currently uses something completely different. I plan on setting this up to be consistent across EclipseLink

"Implementation-Version" in the manifest:
Option 1:
(version)(type)-(date).(revision) or (version)-(date).(revision)
1.1SNAPSHOT-20081006.2312
1.1M3-20081029.2739
1.1-20081125.2984

Option 2:
(version).(type).(revision) or (version).(date).(revision)
1.1.20081006.2312
1.1.M3.2739
1.1.20081125.2984

Option 3 (+1):
(version).(revision)-(type) or (version).(revision)
1.1.2312-SNAPSHOT
1.1.2739-M3
1.1.2984

The first option results in a string closest to what we currently use (but with the addition of the revision).

The second is the result of minimally changing the build methodology.

The third makes the most sense to me. It gives the version and a unique build identifier (revision), is clean and easy to on the eyes, yet still has distinctions for nightly, milestone and release builds. However it diverges significantly from what we currently use.

Thanks.

-Eric

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Re: Re: Version Class changes and the Manifest file

2008-10-06T13:16:00Z

Point taken, and I agree there could be confusion (though 1.1.1 would
look like 1.1.1.2991-SNAPSHOT or 1.1.1.3267 (release)).

Therefore we should ALWAYS specify all the digits in our version. If we
are going to use a three number versioning scheme
(major).(minor).(bugfix), then we should always display the full version.

ie. 1.1.0.2984 and 1.1.1.3267

-Eric

Tom Ware wrote:

> I am concerned that will cause confusion at release time.
>
> If we're not careful, it may look like we just released version
> 1.1.2984. If at some point, we release version 1.1.1, it will look
> like version 1.1.2984 is more recent, when in fact it is less recent.
>
> Are these changes just for manifest files, or also for jar file naming?
>
> -Tom
>
> Eric Gwin wrote:
>> Sounds like Option 4:
>> -----------------------
>> It does distinguish revision from the version. Though I put the
>> period in because it blends it all into a single "Version Number".
>>
>> -Eric
>>
>> Tom Ware wrote:
>>> In your proposed solution, can we change the last "." to some other
>>> character
>>>
>>> e.g.
>>> 1.1-2312-SNAPSHOT
>>>
>>>
>>> Eric Gwin wrote:
>>>> Seems to be little interest on the topic, but I need to at least
>>>> pass this by the group so I'd like a vote today.
>>>>
>>>> I'll put a +1 next to my choice. If there are no other votes, I
>>>> guess it'll win by default.
>>>>
>>>> As an aside, MW currently uses something completely different. I
>>>> plan on setting this up to be consistent across EclipseLink
>>>>
>>>>
>>>> "Implementation-Version" in the manifest:
>>>> _Option 1:_
>>>> (version)(type)-(date).(revision) or (version)-(date).(revision)
>>>> 1.1SNAPSHOT-20081006.2312
>>>> 1.1M3-20081029.2739
>>>> 1.1-20081125.2984
>>>>
>>>> _Option 2:_
>>>> (version).(type).(revision) or (version).(date).(revision)
>>>> 1.1.20081006.2312
>>>> 1.1.M3.2739
>>>> 1.1.20081125.2984
>>>>
>>>> _Option 3 (+1):_
>>>> (version).(revision)-(type) or (version).(revision)
>>>> 1.1.2312-SNAPSHOT
>>>> 1.1.2739-M3
>>>> 1.1.2984
>>>>
>>>> The first option results in a string closest to what we currently
>>>> use (but with the addition of the revision).
>>>>
>>>> The second is the result of minimally changing the build methodology.
>>>>
>>>> The third makes the most sense to me. It gives the version and a
>>>> unique build identifier (revision), is clean and easy to on the
>>>> eyes, yet still has distinctions for nightly, milestone and release
>>>> builds. However it diverges significantly from what we currently use.
>>>>
>>>> Thanks.
>>>>
>>>> -Eric
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> eclipselink-dev mailing list
>>>> eclipselink-dev@...
>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>> _______________________________________________
>>> eclipselink-dev mailing list
>>> eclipselink-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>>
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Re: Release plan for OpenEJB 3.0.x and 3.1

2008-10-06T13:04:47Z

+1
for support of either ActiveMQ 5.1 or 5.2. Not sure if it's to late for this but this would be a huge success since there some nice features in 5.1+ that are not available in 4.1.1

hgomez wrote:

> I just rebuild an OpenEJB 3.1-SNAPSHOT and could see
>
> - OpenJPA 1.1.0 will be included, but I wonder if we could use also
> EclipseLink ?
>
> - CXF 2.0.4 is included and JAXB is 2.0.5. Could we use OpenEJB 3.1
> with JAXWS 2.1.4 and JAXB 2.1.8 ?

And what about ActiveMQ ? Will it be the 4.1 or 5.1 (or 5.2) ?

Thanks

From forum: OpenEJB Dev

Re: Re: Version Class changes and the Manifest file

2008-10-06T12:56:50Z

I am concerned that will cause confusion at release time.

If we're not careful, it may look like we just released version 1.1.2984. If at
some point, we release version 1.1.1, it will look like version 1.1.2984 is more
recent, when in fact it is less recent.

Are these changes just for manifest files, or also for jar file naming?

-Tom

Eric Gwin wrote:

> Sounds like Option 4:
> -----------------------
> It does distinguish revision from the version. Though I put the period
> in because it blends it all into a single "Version Number".
>
> -Eric
>
> Tom Ware wrote:
>> In your proposed solution, can we change the last "." to some other
>> character
>>
>> e.g.
>> 1.1-2312-SNAPSHOT
>>
>>
>> Eric Gwin wrote:
>>> Seems to be little interest on the topic, but I need to at least pass
>>> this by the group so I'd like a vote today.
>>>
>>> I'll put a +1 next to my choice. If there are no other votes, I guess
>>> it'll win by default.
>>>
>>> As an aside, MW currently uses something completely different. I plan
>>> on setting this up to be consistent across EclipseLink
>>>
>>>
>>> "Implementation-Version" in the manifest:
>>> _Option 1:_
>>> (version)(type)-(date).(revision) or (version)-(date).(revision)
>>> 1.1SNAPSHOT-20081006.2312
>>> 1.1M3-20081029.2739
>>> 1.1-20081125.2984
>>>
>>> _Option 2:_
>>> (version).(type).(revision) or (version).(date).(revision)
>>> 1.1.20081006.2312
>>> 1.1.M3.2739
>>> 1.1.20081125.2984
>>>
>>> _Option 3 (+1):_
>>> (version).(revision)-(type) or (version).(revision)
>>> 1.1.2312-SNAPSHOT
>>> 1.1.2739-M3
>>> 1.1.2984
>>>
>>> The first option results in a string closest to what we currently use
>>> (but with the addition of the revision).
>>>
>>> The second is the result of minimally changing the build methodology.
>>>
>>> The third makes the most sense to me. It gives the version and a
>>> unique build identifier (revision), is clean and easy to on the eyes,
>>> yet still has distinctions for nightly, milestone and release builds.
>>> However it diverges significantly from what we currently use.
>>>
>>> Thanks.
>>>
>>> -Eric
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> eclipselink-dev mailing list
>>> eclipselink-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Re: Re: Version Class changes and the Manifest file

2008-10-06T12:27:37Z

Sounds like Option 4:
-----------------------
It does distinguish revision from the version. Though I put the period
in because it blends it all into a single "Version Number".

-Eric

Tom Ware wrote:

> In your proposed solution, can we change the last "." to some other
> character
>
> e.g.
> 1.1-2312-SNAPSHOT
>
>
> Eric Gwin wrote:
>> Seems to be little interest on the topic, but I need to at least pass
>> this by the group so I'd like a vote today.
>>
>> I'll put a +1 next to my choice. If there are no other votes, I guess
>> it'll win by default.
>>
>> As an aside, MW currently uses something completely different. I plan
>> on setting this up to be consistent across EclipseLink
>>
>>
>> "Implementation-Version" in the manifest:
>> _Option 1:_
>> (version)(type)-(date).(revision) or (version)-(date).(revision)
>> 1.1SNAPSHOT-20081006.2312
>> 1.1M3-20081029.2739
>> 1.1-20081125.2984
>>
>> _Option 2:_
>> (version).(type).(revision) or (version).(date).(revision)
>> 1.1.20081006.2312
>> 1.1.M3.2739
>> 1.1.20081125.2984
>>
>> _Option 3 (+1):_
>> (version).(revision)-(type) or (version).(revision)
>> 1.1.2312-SNAPSHOT
>> 1.1.2739-M3
>> 1.1.2984
>>
>> The first option results in a string closest to what we currently use
>> (but with the addition of the revision).
>>
>> The second is the result of minimally changing the build methodology.
>>
>> The third makes the most sense to me. It gives the version and a
>> unique build identifier (revision), is clean and easy to on the eyes,
>> yet still has distinctions for nightly, milestone and release builds.
>> However it diverges significantly from what we currently use.
>>
>> Thanks.
>>
>> -Eric
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@...
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Re: Container Type of SingletonContainer.

2008-10-06T12:20:42Z

On Oct 3, 2008, at 5:44 AM, Manu George wrote:

> Hi,
> The SingletonContainer has a type STATELESS. Shouldn't we have
> another type for singleton?
>

Good catch. Seems that property of the container is only used for
logging on startup so it was missed. Will have to make a mental note
of that for next time.

Thanks!

-David

From forum: OpenEJB Dev

Re: Re: Version Class changes and the Manifest file

2008-10-06T12:08:26Z

In your proposed solution, can we change the last "." to some other character

e.g.
1.1-2312-SNAPSHOT

Eric Gwin wrote:

> Seems to be little interest on the topic, but I need to at least pass
> this by the group so I'd like a vote today.
>
> I'll put a +1 next to my choice. If there are no other votes, I guess
> it'll win by default.
>
> As an aside, MW currently uses something completely different. I plan on
> setting this up to be consistent across EclipseLink
>
>
> "Implementation-Version" in the manifest:
> _Option 1:_
> (version)(type)-(date).(revision) or (version)-(date).(revision)
> 1.1SNAPSHOT-20081006.2312
> 1.1M3-20081029.2739
> 1.1-20081125.2984
>
> _Option 2:_
> (version).(type).(revision) or (version).(date).(revision)
> 1.1.20081006.2312
> 1.1.M3.2739
> 1.1.20081125.2984
>
> _Option 3 (+1):_
> (version).(revision)-(type) or (version).(revision)
> 1.1.2312-SNAPSHOT
> 1.1.2739-M3
> 1.1.2984
>
> The first option results in a string closest to what we currently use
> (but with the addition of the revision).
>
> The second is the result of minimally changing the build methodology.
>
> The third makes the most sense to me. It gives the version and a unique
> build identifier (revision), is clean and easy to on the eyes, yet still
> has distinctions for nightly, milestone and release builds. However it
> diverges significantly from what we currently use.
>
> Thanks.
>
> -Eric
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@...
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Re: Re: Version Class changes and the Manifest file

2008-10-06T11:53:06Z

Seems to be little interest on the topic, but I need to at least pass this by the group so I'd like a vote today.

I'll put a +1 next to my choice. If there are no other votes, I guess it'll win by default.

As an aside, MW currently uses something completely different. I plan on setting this up to be consistent across EclipseLink

"Implementation-Version" in the manifest:
Option 1:
(version)(type)-(date).(revision) or (version)-(date).(revision)
1.1SNAPSHOT-20081006.2312
1.1M3-20081029.2739
1.1-20081125.2984

Option 2:
(version).(type).(revision) or (version).(date).(revision)
1.1.20081006.2312
1.1.M3.2739
1.1.20081125.2984

Option 3 (+1):
(version).(revision)-(type) or (version).(revision)
1.1.2312-SNAPSHOT
1.1.2739-M3
1.1.2984

The first option results in a string closest to what we currently use (but with the addition of the revision).

The second is the result of minimally changing the build methodology.

The third makes the most sense to me. It gives the version and a unique build identifier (revision), is clean and easy to on the eyes, yet still has distinctions for nightly, milestone and release builds. However it diverges significantly from what we currently use.

Thanks.

-Eric

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

[jira] Closed: (CAY-1115) Prefetch on SelectQueries doesn't resolve ToOneFaults

2008-10-06T11:39:12Z

[ https://issues.apache.org/cayenne/browse/CAY-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrus Adamchik closed CAY-1115.
--------------------------------

Resolution: Won't Fix

> Prefetch on SelectQueries doesn't resolve ToOneFaults
> -----------------------------------------------------
>
> Key: CAY-1115
> URL: https://issues.apache.org/cayenne/browse/CAY-1115
> Project: Cayenne
> Issue Type: Bug
> Components: Cayenne Core Library
> Affects Versions: 1.2 [STABLE]
> Environment: 1.2.4 on Linux
> Reporter: Robert Wruck
> Assignee: Andrus Adamchik
>
> final SelectQuery q = new SelectQuery(MyObject.class);
> q.addPrefetch("myRelObject");
> final List l = dataContext.performQuery(q);
> For each element in the returned List, myRelObject is a ToOneFault that will be resolved by a separate query.
> This result is not affected by setSemantics on the prefetch (JOINT, DISJOINT behave just the same way).
> Expected result: myRelObject is filled with the prefetched entity object.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Cayenne - Dev

SVM Commit: Bug#249198 - Query cache does not work in JPA

2008-10-06T11:26:17Z

SVM Commit: Bug#249198 - Query cache does not work in JPA

https://bugs.eclipse.org/bugs/show_bug.cgi?id=249198

also,

Summary of all changes made in patch:

- Fixed EJBQueryImpl to clone the database query only when required, to allow

the query cache to work.

- Changed deploy to log exception on failure.

- Fixed performance testing emulated driver null-pointer in date.

- Added persistence properties for flush-mode and persist-on-commit to allow

performance tuning.

- Changed JPA queries to be processed by the Session on login, instead of by

the JPA setup deploy, this allows for customization of the database queries in

a SessionCustomizer or postConnect event.

- Changed PersistenceProperties to throw an error for an invalid missing

property, instead of silently failing.

- Fixed JPA setup to process profiler property correctly.

- Added support in the UnitOfWork for bypassing discover of new objects on

commit.

- Set the name of the mapping's selection query to be the attribute name.

- Removed parse cache setting from DatabaseQuery, as no longer required.

- Added new tests for new properties.

- Changed hint tests to get query after setting hint.

- Fixed advanced property tests to actually work. They were asserting true,

which is always true. (there was a profiler test, but it did not work)

- Added a JPA test for using a query cache.

Code review: Andrei (pending)

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

From forum: EclipseLink - Dev

Re: Open EJB trunk build failed

2008-10-06T11:06:30Z

I can do a full build with tests and assembly.

It appears that you are getting a failure from one of the itests. Can
you post the report from the failing test?

-dain

On Oct 6, 2008, at 6:39 AM, Henri Gomez wrote:

>> Tests in error:
>>
>> Tests run: 1026, Failures: 0, Errors: 1, Skipped: 0
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] There are test failures.
>>
>> Please refer to
>> C:\workspace-oss\openejb\server\openejb-ejbd\target\surefire-reorts
>> for the individual test results.
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] For more information, run Maven with the -e switch
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 7 minutes 53 seconds
>> [INFO] Finished at: Fri Oct 03 09:53:38 CEST 2008
>>
>>
>> Question, should we disable the test phases ?
>
> FYI, I could do the build by disabling the test phases

From forum: OpenEJB Dev

[jira] Commented: (CAY-1115) Prefetch on SelectQueries doesn't resolve ToOneFaults

2008-10-06T11:02:11Z

[ https://issues.apache.org/cayenne/browse/CAY-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141#action_13141 ]

Robert Wruck commented on CAY-1115:
-----------------------------------

Hi Andrus,

after some debugging, it turned out today that in some cases the number of fetched objects exceeded the DataRowStore size... DOH!
I was fooled by the fact that the relationships are initially populated with a ToOneFault that normally gets resolved from the local cache.
Please close this one.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Cayenne - Dev

[jira] Closed: (CAY-890) CM Cosmetics: Use the Cayenne Icon.

2008-10-06T10:49:11Z

[ https://issues.apache.org/cayenne/browse/CAY-890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrey Razumovsky closed CAY-890.
---------------------------------

Resolution: Fixed
Fix Version/s: 3.0

Committed changes. I can only confirm everything's ok on Win and Linux, please tell me if something's wrong on Mac

> CM Cosmetics: Use the Cayenne Icon.
> -----------------------------------
>
> Key: CAY-890
> URL: https://issues.apache.org/cayenne/browse/CAY-890
> Project: Cayenne
> Issue Type: Improvement
> Components: CayenneModeler GUI
> Reporter: Thomas Bernhard
> Assignee: Andrey Razumovsky
> Priority: Minor
> Fix For: 3.0
>
> Attachments: 890.zip
>
>
> All Frames and Dialogs should use the Cayenne Icon, not the default java icon - branding is important :).
> This should be so even for the generic distributions (not just the native ones).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Cayenne - Dev

Re: Eclipse plugin & libraries

2008-10-06T10:04:05Z

Jonathan Gallimore kirjoitti:

Ok, just make sure you add any and all the jars in that directory to the
project classpath, and not just a fixed set.
Also, it seems that the publish functionality is broken (nothing happens
when you try to publish). Can you verify this?

> Jon
>
> Alex Grönholm wrote:
>> I recently installed the "Apache OpenEJB WTP Runtime 1.0.0" and found
>> that it only includes a few libraries when added to a project. In my
>> opinion, the runtime should add all of the libraries from openejb/lib
>> to the project, like the JBoss runtime does. This is necessary for,
>> among other things, unit testing since all of the server's requisites
>> must be on the classpath. I do not know the current state of affairs
>> with the plugin, so could someone comment on this please?
>
>

From forum: OpenEJB Dev

Re: Eclipse plugin & libraries

2008-10-06T09:45:06Z

Hi Alex,

Thanks for downloading the plugin and giving it a go. I guess at the
moment, we'd regard it as beta. I'm currently working on a couple of
final features and was then going to see if everybody thought it was
ready for a release.

In terms of the classpath, you're right, we only add openejb-client,
javaee-api and optionally ejb31-api-experimental if you want it. It
hasn't caused me any problems with testing (probably because I deploy to
a standalone server and hit the beans as if I'm a remote client when I'm
testing the plugin). I'm certainly happy to add the other jars in the
openejb/lib folder to the project classpath. If there's no objections,
I'll probably be able to get the change committed and the update site
updated this evening.

Jon

Alex Grönholm wrote:
> I recently installed the "Apache OpenEJB WTP Runtime 1.0.0" and found
> that it only includes a few libraries when added to a project. In my
> opinion, the runtime should add all of the libraries from openejb/lib
> to the project, like the JBoss runtime does. This is necessary for,
> among other things, unit testing since all of the server's requisites
> must be on the classpath. I do not know the current state of affairs
> with the plugin, so could someone comment on this please?

From forum: OpenEJB Dev