[jira] Commented: (COCOON-1790) VerifyException "Attempt to split long or double on the stack" in javaflow
[ http://issues.apache.org/jira/browse/COCOON-1790?page=comments#action_12369000 ] Ugo Cei commented on COCOON-1790: - Did you try it with Sun's JDK as well? > VerifyException "Attempt to split long or double on the stack" in javaflow > -- > > Key: COCOON-1790 > URL: http://issues.apache.org/jira/browse/COCOON-1790 > Project: Cocoon > Type: Bug > Components: Blocks: Java Flow > Versions: 2.1.9-dev (current SVN) > Reporter: Simone Gianni > > When writing code like this : > long time = System.currentTimeMillis(); > Date date = new Date(time); > the given exception is thrown. It's a validation exception. This happens > when a long (maybe also a double?) is used in a constructor (not in a > function call). The following code is a workaround : > Date date = new Date(); > date.setTime(time); > but can be used only when the object we are instantiating have a getter as an > alternative to the constructor parameter. > I'm having this problem with a fresh (yesterday) checkout of cocoon 2.1.X > branch. Don't know yet if this apply to other versions of cocoon. I'm using > Blackdown-1.4.2-02 on a 2.6.12-gentoo-r6 linux machine. > Googling around it seems that this exception is raised when the data type in > a pop2 JVM instruction is not correct. I think this is one of the > side-effects of the javaflow BCEL manipulations, but I'm not skilled enought > on BCEL and similar stuff to even think of a possible solution. > The exception is raised loading the javaflow class, so it will prevent the > entire flow (and not only the affected method) to be used. Also, the > exception will just tell you that the class is invalid, and not point you to > the place in code where this long is used in a constructor, so you'll have to > spot it by hand. > I can produce a test case to try to narrow it down, but the given 3 lines of > code are enought to produce the error in my javaflows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Docs] FAQ Document Type
On Sat, 2006-03-04 at 19:04 +, Ross Gardler wrote: > Bruno Dumon wrote: > > On Wed, 2006-03-01 at 14:01 +, Ross Gardler wrote: > > > >>A couple of weeks ago I promised to set up a FAQ system in Daisy. I've > >>now done this. > >> > >>Creating a FAQ > >>== > >> > >>There is a "FAQ" document Type. This is a simple document in which the > >>document title should be the question and the content should be the answer. > >> > >>To illustrate things I have copied the "installation faqs" from > >>http://cocoon.apache.org/2.1/faq/faq-install.html into individual FAQ > >>documents, for example: > >> > >>http://cocoon.zones.apache.org/daisy/documentation/799.html?branch=1&language=1 > >>http://cocoon.zones.apache.org/daisy/documentation/806.html?branch=1&language=1 > >> > > > > > > > >> > >> > >>So, if people like this, we should migrate all FAQs from the legacy docs > >>into this format, as well as including relevant ones from the Wiki. > >> > >>Ross > > > > > > Thanks for setting this up. I have some reservations though about > > copying the FAQs from the legacy docs. I haven't read them all but a lot > > of them have become either incorrect or irrelevant. One of the reasons > > for the "new documentation" is that we can leave behind the outdated > > information. > > Yes, that makes sense, I'm a little behind with Cocoon, so do not have > the knowledge to decide what goes in and what stays out. > > > I'd also like to change the > > query in the navigation to a query in a document: having the long > > questions in the navigation doesn't make sense I think. > > +1 > > I only really threw these in as examples. Later I realised I had not > done an example of creating a complete FAQ document (i.e. with questions > & answers) only of indexes (bth navigation and in document). > > None daisy users should be aware that the query system in Daisy is > superb and very flexible. If folk want something better than is > currently in place then just ask how (or do it). > I now made this of it: http://cocoon.zones.apache.org/daisy/documentation/856.html I've added a forms-related FAQ and a flowscript-related FAQ. > > Similar to the FAQ doctype, I'd also like to set up a "GlosarryItem" > > doctype which can be used to provide short explanations of > > Cocoon-specific terms (such as sitemap, subsitemap, FOM, flowscript, > > blocks, real blocks, ...). > > +1 And the glossary is here: http://cocoon.zones.apache.org/daisy/documentation/857.html -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [2.2] Support for per sitemap classloading?
Reinhard Poetz wrote: > IIUC the classloading as you describe it here isn't in place, right? Yupp. > Currently > we have one global classloader for *all* blocks (see the BlocksManager). The > build system (= Maven 2) takes care that only one version of each artifact is > added to the global classloader. Ok. > > This will change with the introduction of the OSGi-based blocks-fw. Then OSGi > will take care of it and that's the reason why we should wait before we come > up > with our own solutions (which hopefully won't be ncessary). Ok, yes, I see your point to wait for OSGi, I was just wondering if we could anticipate the outcome and do something today. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Closed: (COCOON-1762) [cocoon-deployer-core] Install a block only once
[ http://issues.apache.org/jira/browse/COCOON-1762?page=all ] Reinhard Poetz closed COCOON-1762: -- Resolution: Fixed works for me > [cocoon-deployer-core] Install a block only once > > > Key: COCOON-1762 > URL: http://issues.apache.org/jira/browse/COCOON-1762 > Project: Cocoon > Type: Sub-task > Components: - Build System: Maven > Reporter: Reinhard Poetz > Assignee: Reinhard Poetz > > A block only needs to be _physically_ available once. We can point to it from > several block definitions in wiring.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1792) [cocoon-deployer-core] Tidy up block.xml schema
[ http://issues.apache.org/jira/browse/COCOON-1792?page=all ] Reinhard Poetz closed COCOON-1792: -- Resolution: Fixed I removed all elements that represent information that is already covered by Maven pom.xml files. I adapted all block.xml (that I found) to validate again against the schema. > [cocoon-deployer-core] Tidy up block.xml schema > --- > > Key: COCOON-1792 > URL: http://issues.apache.org/jira/browse/COCOON-1792 > Project: Cocoon > Type: Sub-task > Components: - Build System: Maven > Reporter: Reinhard Poetz > Assignee: Reinhard Poetz > > block.xml has some values that are already available in pom.xml (author, > license, ...) - remove them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1791) [cocoon-deployer-core] Make exclusive mode settable by the client library (e.g. the maven-plugin)
[ http://issues.apache.org/jira/browse/COCOON-1791?page=all ] Reinhard Poetz closed COCOON-1791: -- Resolution: Fixed attribute "exclusive" was removed from cocoon-deploy.xml schema; adapted all block.xml files (that I found) so that they validate against the new schema again. I also adapted code that relies on the generated Java sources > [cocoon-deployer-core] Make exclusive mode settable by the client library > (e.g. the maven-plugin) > - > > Key: COCOON-1791 > URL: http://issues.apache.org/jira/browse/COCOON-1791 > Project: Cocoon > Type: Sub-task > Components: - Build System: Maven > Reporter: Reinhard Poetz > Assignee: Reinhard Poetz > > Currently the "exclusive mode" is set as attribute of the -element in > the deployment descriptor. I think that's wrong as this shouldn't be part of > the deployment descriptor (describes WHAT has to be deployed but not HOW) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [2.2] Support for per sitemap classloading?
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
One remaining question: currently we have several places where the
thread context classloader is used (for example to create new
instances). I guess that with the blocks-fw in place that the thread
context class loader is not the correct one.
why do you think so? (just curious, I haven't had the idea yet that this could
be a problem)
Blocks provide isolated class loading, so every block has it's own class
loader. Now, unless you want to change the thread context class loader
on each method invokation between blocks (like we currently do for the
environment stack with internal pipeline calls), then the thread context
class loader is rarely the class loader for the "current" block.
We currently use the thread context class loader to get "cocoon's
classloader" which might be different (in 2.1.x) to the webapp class loader.
IIUC the classloading as you describe it here isn't in place, right? Currently
we have one global classloader for *all* blocks (see the BlocksManager). The
build system (= Maven 2) takes care that only one version of each artifact is
added to the global classloader.
This will change with the introduction of the OSGi-based blocks-fw. Then OSGi
will take care of it and that's the reason why we should wait before we come up
with our own solutions (which hopefully won't be ncessary).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Support for per sitemap classloading?
Reinhard Poetz wrote: > Carsten Ziegeler wrote: > >> One remaining question: currently we have several places where the >> thread context classloader is used (for example to create new >> instances). I guess that with the blocks-fw in place that the thread >> context class loader is not the correct one. > > why do you think so? (just curious, I haven't had the idea yet that this > could > be a problem) > Blocks provide isolated class loading, so every block has it's own class loader. Now, unless you want to change the thread context class loader on each method invokation between blocks (like we currently do for the environment stack with internal pipeline calls), then the thread context class loader is rarely the class loader for the "current" block. We currently use the thread context class loader to get "cocoon's classloader" which might be different (in 2.1.x) to the webapp class loader. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Support for per sitemap classloading?
Daniel Fagerstrom wrote:
What the blocks fw eventually will support depends on what you and
others want it to support and are prepared to implement ;)
Yes, that's the plan. Adding it to
org.apache.cocoon.blocks.servlet.BlocksManager (module:
cocoon-blocks-fw-servlet-impl) shouldn't be too difficult, especially
for you ;-)
But as said in my other response to Carsten's mail, adding it to the
OSGi framework (Equinox and/or Felix) will be more difficult.
I haven't evaluated all the details, but IMHO the difficulty of adding
dynamic classloading in OSGi depends on what you what to achieve. In
OSGi classes in the main classloader of a bundle are imported, exported
or internal. For classes that a bundle export dynamic class loading is
more complicated as all bundles that import the class must be refreeshed
when the class is updated.
But dynamic classloading in Cocoon has always been about isolated, e.g.
sitemap local class loading. As long as we are happy with bundle
internal classloading, it shouldn't be much different from the sitemap
local dynamic classloading of today.
ok
For inter bundle (block) dependencies, you can always stop, update, and
restart a bundle and refresh the OSGi framework, and the application
will work again with the new code (given that all services are dynamic
aware).
I think, what we need is a hook that the "stop, update and restart" process is
done automatically, if the system is in "development mode". I just don't want to
do it myself.
If you have some time, it would be really great if you could have a
look at it. IMO the ReloadingClassloader is one of the most important
features that we should add (developing [web]apps without it, isn't
fun anymore for me).
It should also be noted that Eclipse is based on OSGi and is rather
dynamic :) So it should be possible to achieve a high degree of dynamism
in OSGi based Cocoon, and we can possibly reuse some Eclipse bundles for
convenient application development.
yes, in the meantime I'm very optimistic that we will find ways to add RAD
capabilities :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Support for per sitemap classloading?
Carsten Ziegeler wrote:
And one additional question :) In 2.1.x you can configure extra
classpath in the web.xml; I think we should remove that feature for
blocks-fw as well, right?
yes, those hacks are not required with blocks any more
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [2.2] Support for per sitemap classloading?
Carsten Ziegeler wrote:
One remaining question: currently we have several places where the
thread context classloader is used (for example to create new
instances). I guess that with the blocks-fw in place that the thread
context class loader is not the correct one.
why do you think so? (just curious, I haven't had the idea yet that this could
be a problem)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
