You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Manu George <ma...@gmail.com> on 2007/10/25 23:41:38 UTC
Re: ejb-jar.xml to Annotations tool (Copyright question)
Hi,
Is the contributed code allowed to contain
Copyright 2007 Jonathan Gallimore
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
Can someone with more legal knowledge reply to this.
Regards
Manu
On 10/24/07, Jonathan Gallimore <jo...@gmail.com> wrote:
> Whoops! I've attached another patch created with TortoiseSVN, hopefully
> that'll do the trick.
>
> The plugin should work with an EJB 2.1 ejb-jar.xml file, I have an old
> version of the Bank sample (I think its a Geronimo sample) which is EJB
> 2.1 and that seems to work. I have had some exceptions with openejb-jee
> unmarshalling EJB 2.0 xml files though. You do need to have the EJB 3
> API classes on your classpath though (although it might be an idea for
> me to check for that, and add it if its not there already). I think it
> would be useful if I put together some documentation and perhaps a
> screencam of it in action.
>
> Glad you like the preview - I forgot to mention I had done that.
> Essentially its works in the same way as any of the other Java
> refactorings. It took a while to figure out how to do it, but was well
> worth it, I think ;-)
>
> Cheers
>
> Jon
>
> Manu George wrote:
> > Hi Jonathan,
> > Sorry for the delay,Can you attach a patch that is
> > created using svn. The current patch has diffs for the svn specific
> > files as well. If you create one using svn it will be easier for me to
> > apply too. There was no error in the error logs because I was using an
> > ejb 2.1 bean :). Once I changed to 3.0 beans it worked like a charm.
> > The diff view is awesome. Great work Jon
> >
> > Thanks
> > Manu
> >
> > On 10/23/07, Jonathan Gallimore <jo...@gmail.com> wrote:
> >
> >> Hi Manu,
> >>
> >> I have attached a patch to JIRA issue OPENEJB-674. I've have applied the
> >> patch to a fresh checkout of the plugin that is already in the sandbox,
> >> and it seemed to work ok, but I had to manually remove the
> >> org.eclipse.jst.server.generic.openejb folder in the root (its now under
> >> the plugins folder). Please let me know if you need anything else.
> >>
> >> Also, did you have any luck getting a stack trace from the error log for
> >> the error message you were encountering?
> >>
> >> Cheers
> >>
> >> Jon
> >>
> >>
> >> Manu George wrote:
> >>
> >>> Hey David, hope you are enjoying your vacation. Jonathan, I will be
> >>> happy to get this into sandbox. Please attach a patch.
> >>>
> >>> Thanks
> >>> Manu
> >>>
> >>>
> >>>
> >
> >
>
>
Re: Tomcat hot deployment
Posted by Dain Sundstrom <da...@iq80.com>.
That's weird. It works for me on Mac Java6, but my objects are
pretty simple.
-dain
On Oct 26, 2007, at 11:14 PM, Dario Laverde wrote:
> Thanks for clarifying.
>
> I figured out my issue with requiring the agent on Java 6, it seems
> to be only an
> issue on the Mac using Java 1.6.0-dp-b88-34 and unfortunately Java
> 6 didn't get
> updated with last night's Leopard release.
>
> It works fine with Java 5, and fine if I install the agent on Java
> 6 and restart, so
> it's currently not optional on the Mac + Java 6
>
> Dario
>
>
> Here's the root cause trace:
>
> java.lang.VerifyError: (class:
> org/apache/openjpa/enhance/net$nycjava$OrderItem$pcsubclass,
> method: writeReplace
> signature: ()Ljava/lang/Object;) Bad access to protected data
> java.lang.Class.forName0(Native Method)
> java.lang.Class.forName(Class.java:247)
> org.apache.openjpa.util.GeneratedClasses.loadBCClass
> (GeneratedClasses.java:67)
> org.apache.openjpa.enhance.ManagedClassSubclasser.write
> (ManagedClassSubclasser.java:257)
> org.apache.openjpa.enhance.ManagedClassSubclasser.access$000
> (ManagedClassSubclasser.java:53)
> org.apache.openjpa.enhance.ManagedClassSubclasser$1.write
> (ManagedClassSubclasser.java:123)
> org.apache.openjpa.enhance.PCEnhancer.record
> (PCEnhancer.java:524)
> org.apache.openjpa.enhance.PCEnhancer.record
> (PCEnhancer.java:512)
>
> org.apache.openjpa.enhance.ManagedClassSubclasser.prepareUnenhancedCla
> sses(ManagedClassSubclasser.java:144)
>
> which causes:
>
> Exception in thread "Attach Listener"
> java.lang.ClassNotFoundException:
> org.apache.openjpa.enhance.InstrumentationFactory
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:
> 287)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at
> sun.instrument.InstrumentationImpl.loadClassAndStartAgent
> (InstrumentationImpl.java:285)
> Agent failed to start!
>
>
>> On Oct 26, 2007, at 11:35 AM, Dario Laverde wrote:
>>
>>> Hi Dain,
>>>
>>> Just a couple of questions, how did you hookup deploying an ear
>>> file into Tomcat's
>>> webapps without requiring a restart or is that a false assumption)?
>>
>> From the restart perspective ears are much easier to deal with then
>> wars, because tomcat completely ignores ear files. When we detect an
>> ear file in the webapp directory, we simply kick off a normal OpenEJB
>> deploy. When we get to the assembler the TomcatWebAppBuilder is
>> notified of the web application and adds new contexts to Tomcat.
>>
>>> Are there any packaging considerations for the ear file - it still
>>> has to be a collapsed correct?
>>
>> The feature I announced is that normal .ear files work. Collapsed
>> ears have worked for a long time.
>>
>>> Is there a test that illustrates an example?
>>
>> Nope. I hacked the itests into an ear structure.
>>
>>> Secondly, although the installer now indicates that the openjpa
>>> agent that requires
>>> a restart is now optional, I still couldn't get my examples working
>>> without it (even
>>> on Java 6 which I assumed openjpa would make use of to avoid the
>>> agent/restart).
>>
>> I stopped running the installer a long time ago and JPA has been
>> working good for me. Can you post a the stacktrace and info about
>> your application?
>>
>> -dain
>>
>
>
Re: Tomcat hot deployment
Posted by Dario Laverde <da...@nycjava.net>.
Thanks for clarifying.
I figured out my issue with requiring the agent on Java 6, it seems to be only an
issue on the Mac using Java 1.6.0-dp-b88-34 and unfortunately Java 6 didn't get
updated with last night's Leopard release.
It works fine with Java 5, and fine if I install the agent on Java 6 and restart, so
it's currently not optional on the Mac + Java 6
Dario
Here's the root cause trace:
java.lang.VerifyError: (class:
org/apache/openjpa/enhance/net$nycjava$OrderItem$pcsubclass, method: writeReplace
signature: ()Ljava/lang/Object;) Bad access to protected data
java.lang.Class.forName0(Native Method)
java.lang.Class.forName(Class.java:247)
org.apache.openjpa.util.GeneratedClasses.loadBCClass(GeneratedClasses.java:67)
org.apache.openjpa.enhance.ManagedClassSubclasser.write(ManagedClassSubclasser.java:257)
org.apache.openjpa.enhance.ManagedClassSubclasser.access$000(ManagedClassSubclasser.java:53)
org.apache.openjpa.enhance.ManagedClassSubclasser$1.write(ManagedClassSubclasser.java:123)
org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:524)
org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:512)
org.apache.openjpa.enhance.ManagedClassSubclasser.prepareUnenhancedClasses(ManagedClassSubclasser.java:144)
which causes:
Exception in thread "Attach Listener" java.lang.ClassNotFoundException:
org.apache.openjpa.enhance.InstrumentationFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:287)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:285)
Agent failed to start!
> On Oct 26, 2007, at 11:35 AM, Dario Laverde wrote:
>
>> Hi Dain,
>>
>> Just a couple of questions, how did you hookup deploying an ear
>> file into Tomcat's
>> webapps without requiring a restart or is that a false assumption)?
>
> From the restart perspective ears are much easier to deal with then
> wars, because tomcat completely ignores ear files. When we detect an
> ear file in the webapp directory, we simply kick off a normal OpenEJB
> deploy. When we get to the assembler the TomcatWebAppBuilder is
> notified of the web application and adds new contexts to Tomcat.
>
>> Are there any packaging considerations for the ear file - it still
>> has to be a collapsed correct?
>
> The feature I announced is that normal .ear files work. Collapsed
> ears have worked for a long time.
>
>> Is there a test that illustrates an example?
>
> Nope. I hacked the itests into an ear structure.
>
>> Secondly, although the installer now indicates that the openjpa
>> agent that requires
>> a restart is now optional, I still couldn't get my examples working
>> without it (even
>> on Java 6 which I assumed openjpa would make use of to avoid the
>> agent/restart).
>
> I stopped running the installer a long time ago and JPA has been
> working good for me. Can you post a the stacktrace and info about
> your application?
>
> -dain
>
Re: Tomcat hot deployment
Posted by Dain Sundstrom <da...@iq80.com>.
On Oct 26, 2007, at 11:35 AM, Dario Laverde wrote:
> Hi Dain,
>
> Just a couple of questions, how did you hookup deploying an ear
> file into Tomcat's
> webapps without requiring a restart or is that a false assumption)?
From the restart perspective ears are much easier to deal with then
wars, because tomcat completely ignores ear files. When we detect an
ear file in the webapp directory, we simply kick off a normal OpenEJB
deploy. When we get to the assembler the TomcatWebAppBuilder is
notified of the web application and adds new contexts to Tomcat.
> Are there any packaging considerations for the ear file - it still
> has to be a collapsed correct?
The feature I announced is that normal .ear files work. Collapsed
ears have worked for a long time.
> Is there a test that illustrates an example?
Nope. I hacked the itests into an ear structure.
> Secondly, although the installer now indicates that the openjpa
> agent that requires
> a restart is now optional, I still couldn't get my examples working
> without it (even
> on Java 6 which I assumed openjpa would make use of to avoid the
> agent/restart).
I stopped running the installer a long time ago and JPA has been
working good for me. Can you post a the stacktrace and info about
your application?
-dain
Re: Tomcat hot deployment
Posted by Dario Laverde <da...@nycjava.net>.
Hi Dain,
Just a couple of questions, how did you hookup deploying an ear file into Tomcat's
webapps without requiring a restart or is that a false assumption)? Are there any
packaging considerations for the ear file - it still has to be a collapsed correct?
Is there a test that illustrates an example?
Secondly, although the installer now indicates that the openjpa agent that requires
a restart is now optional, I still couldn't get my examples working without it (even
on Java 6 which I assumed openjpa would make use of to avoid the agent/restart).
thanks,
Dario
Re: ejb-jar.xml to Annotations tool (Copyright question)
Posted by Dain Sundstrom <da...@iq80.com>.
You can find a pile of information here (http://www.apache.org/legal/
src-headers.html), but to summarize the code need to contain only the
standard apache licence header without any additional copyright
notices. Also we don't use @author javadoc tags.
-dain
On Oct 25, 2007, at 2:41 PM, Manu George wrote:
> Hi,
> Is the contributed code allowed to contain
>
> Copyright 2007 Jonathan Gallimore
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing,
> software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
> or implied.
> + * See the License for the specific language governing
> permissions and
> + * limitations under the License.
> + */
> +
>
> Can someone with more legal knowledge reply to this.
>
> Regards
> Manu
>
> On 10/24/07, Jonathan Gallimore <jo...@gmail.com> wrote:
>> Whoops! I've attached another patch created with TortoiseSVN,
>> hopefully
>> that'll do the trick.
>>
>> The plugin should work with an EJB 2.1 ejb-jar.xml file, I have an
>> old
>> version of the Bank sample (I think its a Geronimo sample) which
>> is EJB
>> 2.1 and that seems to work. I have had some exceptions with
>> openejb-jee
>> unmarshalling EJB 2.0 xml files though. You do need to have the EJB 3
>> API classes on your classpath though (although it might be an idea
>> for
>> me to check for that, and add it if its not there already). I
>> think it
>> would be useful if I put together some documentation and perhaps a
>> screencam of it in action.
>>
>> Glad you like the preview - I forgot to mention I had done that.
>> Essentially its works in the same way as any of the other Java
>> refactorings. It took a while to figure out how to do it, but was
>> well
>> worth it, I think ;-)
>>
>> Cheers
>>
>> Jon
>>
>> Manu George wrote:
>>> Hi Jonathan,
>>> Sorry for the delay,Can you attach a patch that is
>>> created using svn. The current patch has diffs for the svn specific
>>> files as well. If you create one using svn it will be easier for
>>> me to
>>> apply too. There was no error in the error logs because I was
>>> using an
>>> ejb 2.1 bean :). Once I changed to 3.0 beans it worked like a charm.
>>> The diff view is awesome. Great work Jon
>>>
>>> Thanks
>>> Manu
>>>
>>> On 10/23/07, Jonathan Gallimore <jo...@gmail.com>
>>> wrote:
>>>
>>>> Hi Manu,
>>>>
>>>> I have attached a patch to JIRA issue OPENEJB-674. I've have
>>>> applied the
>>>> patch to a fresh checkout of the plugin that is already in the
>>>> sandbox,
>>>> and it seemed to work ok, but I had to manually remove the
>>>> org.eclipse.jst.server.generic.openejb folder in the root (its
>>>> now under
>>>> the plugins folder). Please let me know if you need anything else.
>>>>
>>>> Also, did you have any luck getting a stack trace from the error
>>>> log for
>>>> the error message you were encountering?
>>>>
>>>> Cheers
>>>>
>>>> Jon
>>>>
>>>>
>>>> Manu George wrote:
>>>>
>>>>> Hey David, hope you are enjoying your vacation. Jonathan, I
>>>>> will be
>>>>> happy to get this into sandbox. Please attach a patch.
>>>>>
>>>>> Thanks
>>>>> Manu
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>