Marker = key in a hasmap or sthg like it.
The point is we use kind of fake loader delegating to real loaders. So
hashCode is effectively equals but equals shouldnt return true from a
strict perspective but if it doesnt do it we are not able to use cdi
correctly (excepted luck or particular case) a
We can definitely start with these:
-
https://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-tomee-tests/
We might want to move those to another section of the repo and make a mirror
for them in github so people have an easy way to run them.
In terms of "what do we do", conv
Lots of good feedback! Going to respond to just dev@tomee.apache.org as to not
bug people. Subscribe to the list or follow along via Nabble:
-
http://openejb.979440.n4.nabble.com/Arquillian-Java-EE-Test-Initiative-td4666503.html
-David
On Dec 2, 2013, at 7:47 PM, David Blevins wrote:
> P
H, ok. I guess I start to understand what the problem is. If I'm right,
we already have a buggy feature. Bear with me.
None of the parents of LazyStopWebappClassLoader implements "hashCode",
therefore our current "LazyStopWebappClassLoader#equals" implementation (at
the least the one just befo
The more obvious issue comes from the fact we and libs like deltaspike use
classloader as marker so if both are not equals when needed it doesnt work
(we dont find cdi context ror instance)
Le 3 déc. 2013 23:34, "Thiago Veronezi" a écrit :
> >>If you have time to add tests it would be great
> I w
>>If you have time to add tests it would be great
I will test it a little bit further.
But I didn't quite get the problem yet... sorry! :)
This is our implementation (without the cache)...
*
pu
well, the issue is without doing it the classloader used for cxf
(http://svn.apache.org/repos/asf/tomee/tomee/trunk/server/openejb-cxf-transport/src/main/java/org/apache/openejb/server/cxf/transport/util/CxfContainerClassLoader.java)
and the webapp loader are different. I'm 100% sure that's a regre
It didn't locally. It takes ~2 hrs to have an exception or not.
It should happen in the next 1:15 hrs. If anything happens we can always
revert it back. :)
On Tue, Dec 3, 2013 at 4:19 PM, Romain Manni-Bucau wrote:
> it does for sure, not sure we have tests btw
> Romain Manni-Bucau
> Twitter:
Side note: I never remember but if hashcode is not cached in Object
native impl we should do it in classloaders. It is called so often it
can be noticeable in some cases
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
it does for sure, not sure we have tests btw
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/12/3 Thiago Veronezi :
> I tested it locally without the methods.
> Committed
I tested it locally without the methods.
Committed the code to see if the build server complains.
[]s,
Thiago.
On Tue, Dec 3, 2013 at 1:11 PM, Romain Manni-Bucau wrote:
> hashcode is just a cached impl, equals is mandatory because of the
> hack we have to isolate a bit cxf from apps.
>
> If yo
there is a single test for it + a lot of routing features of JAXRS are
not supported + the config is far more verbose than using application
That said it shouldnt deploy/undeploy. Just deploy each endpoint separately.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
What it would be the disavantage exactly using the system.properties?
I would like to dont change the Endpoint and update the project using it.
--
View this message in context:
http://openejb.979440.n4.nabble.com/No-root-resource-matching-request-path-tp4666495p4666531.html
Sent from the OpenEJ
hashcode is just a cached impl, equals is mandatory because of the
hack we have to isolate a bit cxf from apps.
If you fix isolation you can remove it ;).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https:
The equals and hashCode look weird.
@Override
public boolean equals(final Object other) {
return other != null && ClassLoader.class.isInstance(other) &&
hashCode() == other.hashCode();
}
@Override
public int hashCode() {
quartz api (interfaces/abstract classes) are sometimes used by users.
If we shade we can't use default impl. Not blocking for me, was mainly
a warning
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://git
Hi
You use a jta datasource with resource local config, is it intended?
Does liferay provides hibernate? If yes set in your persistence
unit
Le 3 déc. 2013 16:27, "pspyra" a écrit :
> I have liferay 6.1 bundled with tomcat 7 (already populated with some data
> from users, that's why I cannot s
Do you mean starting from our own tests or creating new ones? I think it
would be better to start by converting our own
https://svn.apache.org/repos/asf/tomee/tomee/trunk/examples/ (where
applicable).
>>How about following the Adopt JSR/OpenJDK initiatives; Adopt a Test :)
This is a great idea! We
I have liferay 6.1 bundled with tomcat 7 (already populated with some
data from users, that's why I cannot switch to liferay bundled with
glassfish) and now I'm trying to develope new portlet with persistence
and the whole EJB stuff.
I found that there should be some way to integrate tomcat 7 wi
Did not get time to dig into, was just my first feeling. Could you
elaborate a bit more?
Not sure I understood the extension issue?
JLouis
2013/12/3 Romain Manni-Bucau
> The 3rd ;). The issue is we loose all quartz extensions then
> Le 3 déc. 2013 10:10, "Jean-Louis MONTEIRO" a écrit :
>
> >
As Romain, I would suggest to put soomething like :
@ApplicationPath("/rest")
public class ApplicationConfig extends Application {
public Set> getClasses() {
return new HashSet>(Arrays.asList(MyService.class));
}
}
Will probably have to adapt your endpoint URI but it should work
1.6.0 uses application oriented deployment to be jaxrs compliant, the mode
you use is a degraded mode kept for compatibility only
Le 3 déc. 2013 11:04, "cri_sys" a écrit :
> Thanks i have fixed the issue, adding the following to the
> system.properties:
>
> openejb.jaxrs.application = false
>
> N
Thanks i have fixed the issue, adding the following to the system.properties:
openejb.jaxrs.application = false
Now my application its running, but something strange its that it runs twice
before really starting, so it runs then destroys, then runs again, taking
longer the startup time, its there
A similar initiative was started a few weeks back; Arquillian'fy all
the JavaEE 7 Samples;
https://github.com/javaee-samples
CI https://arungupta.ci.cloudbees.com/
So far it's been rallied via Hackergartens on verious conferences/jugs
which has been fairly successful. These are EE7 samples so it'
The 3rd ;). The issue is we loose all quartz extensions then
Le 3 déc. 2013 10:10, "Jean-Louis MONTEIRO" a écrit :
> Maybe the second (shaded) one is easier to manage at first glance.
> So that is my preferred solution
>
>
> 2013/12/3 Romain Manni-Bucau
>
> > Ps: forgot another solutuon: shade q
Maybe the second (shaded) one is easier to manage at first glance.
So that is my preferred solution
2013/12/3 Romain Manni-Bucau
> Ps: forgot another solutuon: shade quartz in org.apache.openejb.quartz
> Le 2 déc. 2013 22:23, "Romain Manni-Bucau" a
> écrit :
>
> > Hi
> >
> > How do we handle q
Hi David,
This sounds great ! I haven't been active for awhile and have been wishing
to contribute more. But hurray ! For the next 2-3 weeks I'd have a lot of
free time and I could get started on this right away.
I might've missed any previous discussions on this, so would like to know
what we ar
Ps: forgot another solutuon: shade quartz in org.apache.openejb.quartz
Le 2 déc. 2013 22:23, "Romain Manni-Bucau" a écrit :
> Hi
>
> How do we handle quartz for next releases? It is very often a pain
>
> I propose:
> 1) if in openejb loader use this one
> 2) if not look for it in tomee/quartz/*.j
28 matches
Mail list logo
